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Introduction 


Welcome to RICIS SYMPOSIUM *88! 


Considerable national interest is concentrated on enhancing productivity to help ensure a U. S. 
competitive advantage in the world marketplace. The technical community has reaUzed the 
imponance of software in meeting this goal for some time (15-20 years!). Over the past three to 
five years, the business community has come to understand and accept the importance of software. 
In fact, software has surpassed hardware as the key element to the success of many products, 
systems and businesses. 

Despite this growing awareness of the importance of software, much work still needs to be done in 
addressing software development issues. Because an increasing number of people have recognized 
the ne^ for a more disciplined approach to software development, "software engineering" is 
emerging as an important professional discipline. Unfortunately many remain unaware of modem 
software engineering methods and procedures, and too many organizations are still developing 
software in a haphazard fashion. 

Given this perspective, plus the fact that the focal point of RICIS research is the NASA Space 
Station Program, "Integrated Environments for Large, Complex Systems" is an appropriate theme 
or RICIS SYWOSIUM 'p. Distinguished professionals from industry, government and academia 
have been invited to participate and present their views and experiences regarding research, 
education and future directions related to this topic. 

Within RICIS, more than half of the research being conducted is in the area of Computer Systems 
and Software Engineering. The focus of this research is on the software development life -cycle for 
large, complex, distributed systems. Within the education and training component of RICIS, the 
primary emphasis has been to provide education and training for software professionals. 

However, RICIS research has grown to the point that it is not feasible to cover the many on-going 
research activities in a single day-and-a-half conference. Hence we have elected to have a series of 
conferences, with each ft^using on a specific technical area or topic of interest within RICIS. An 
overview of the accomplishments to date, research plans for the coming year, and upcoming 

conferences will be presented by the RICIS research area directors for each of the five RICIS 
re.search areas. 

We hope you find RICIS SYPOSIUM '88 both informative and enjoyable! 




1 


A. Glen Houston 
Technical Co-Chair 


Robert B. MacDonald 
Technical Co-Chair 




Table of Contents 

Program Agenda i 

Keynote Speaker 

Larry E. DrufTel 

Software Development Environments: Status and Trends 1 



RICIS Research Review 9 

Charles W. McKay 

Computer Systems and Software Engineering 1 1 

Peter C. Bishop 

Research Review for Information Management 1 7 

Terry Feagin 

Artificial Intelligence and Expert Systems 27 

A. Glen Houston 

Mathematical and Statistical Analysis 33 

Glenn B. Freedman 

Research Review for Software Engineering and Training 37 

Session I Requirements Analysis Fundamentals 43 

Colin Potts 

Requirements Analysis, Domain Knowledge, and Design 45 

Lawrence Z. Markosian 

Knowledge-Based Reqirements Analysis for Automating Software Development 57 


Dinner Speaker 

Frank Belz 

Integrated Software Support Environments: Some Lessons Learned 69 

Session II Space Station Software Support Environments 71 


Tim Porter and Paul Babick 

Lessons Learned from an ADA Conversion Project 73 

Gokul Bhaumik 

Modernization of Software Quality Assurance 85 

Herb Krasner 

Empirical Studies of Design Software: 

Implications for Software Engineering Environments 93 

C. T. Shotton and C. L. Carmody 

Tool Interoperability in SSE 01 2.0 99 




Session III Developing Software Engineering for 

Competitive Advatage-Industry and 

Federal Government 113 

Dana L. Hall 

The Role of Software Engineering in the Space Station Program 115 

John B. Munson 

Unisys' Experience in Software Quality and Productivity 

Management of an Existing System 117 

Howard Yudkin 

Next Generation 125 


Panel I Software Engineering as an 

Engineering Discipline 127 

Glenn B. Freedman 

Software Engineering as an Engineering Discipline 129 

John W. Brackett 

Meeting the Challenge of Industrial Software Development: 

The Boston University Graduate Program in Software Systems Engineering 1 35 

Edward V. Berard 

Software Engineering as an Engineering Discipline 149 

Robert B. MacDonald 

Software Engineering as an Academic Discipline 1 59 

Norman Gibbs 

Software Engineering as an Engineering Discipline 1 6 1 


Panel II Computer-Aided Software 

Engineering Environments 

for Real-Time Systems 177 

Charles W. McKay 

A Conceptual Model for Evolving Run Time Support of Mission and Safety Critical 
Components in Large, Complex, Distributed Systems 179 

Miguel A. Carrio 

A New Technology Perspective and Engineering Approach for Large, Complex and 
Distributed Mission and Safety Critical Systems Cort^onets 201 

E.Douglas Jensen 

Alpha: A Real-Time Decentralized Operating System for Mission-Oriented 

System I ntegration and Operation 213 



Integrated Computing Environments 
for Large, Complex Systems 


Wednesday November 9,1 988 


12 . 30 - 1:00 


Welcomes and Introductions Crystal Ballroom 


A. Glen Houston 

Conference Technical Co-Chair, Director RICIS 
UH-Clear Lake 

Robert B. MacDonald 
Conference Technical Co-Chair 

Assistant for Research and Education Mission Support Directorate 
NASA/Johnson Space Center 

Michael C. Cemignani 

Senior Vice President and Provost 

UH-Clear Lake 


Joseph P. Loftus, Jr. 

Assistant Director (PLANS) 
Office of Director 
NASA/Johnson Space Center 


1 : 00 - 1:45 


Crystal Ballroom 


Keynote Address 
Software Development Environments: 
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significant opportunity for improved productivity. A collection of tools is not 
opportunity, the environment must support a disciplined software engineering process and 
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330 RICIS Research Review Crystal Ballroom 

ciwrTakr''°"' Institute (or Computing and Infonnation Systems IRICISI, University of Houston- 

St",?a,t^eKamhS^^^^^ ""'i" mClS. Each project director will summarize his 
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Mathematical and Statistical Analysis-A. Glen Houston 
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Requirements Analysis Fundamentals 
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Requirements Analysis, Domain Knowledge and Design 

Colin Potts 

domain modeling, should facilitate iterative design encoSraKeThe reuJeofd!:.^" alternative, more stable approach, 
f-eaf fraceability mo,e fcmally. Such techniques a're new wrth the exf^f^telletfwfSk ™'' 

SifeS‘LondTn?’™7wa^ fnresttlm foM™ 'Klured af Imperial 

anafysisand focmaf specifications UKhniques ffiUurrentresMm&™"t‘*“T a addressing requiremems 

and hypertexi applicafions in software en^needng design methods 


Knowledge-Based Requirements Analysis for Automating Software Development 

Lawrence Markosian 

developmern. It shoviTh'?w'to%Xanze reSreS^ an^^^ support the automation of software 

validate the formalized requirementrand simuTtan3v app y domam-speci ic analysis techniques to 

programming knowledge can then be applied to the function^ tnpHf (unctional specifications. General 

validated requirements ^ functional specifications to yield executable code that meets the 

fec-mSS fTRjInlized m compufed assisu-d insfrurTiun uf 

Reasoning Sysiems, inc LiwrXe P,°‘^ Wfcalions. As ,r founder of 

ccmmunicalion, program franslaliorr, Ol. equipmen, configuralrdnSyoXi'ptnnlngTnd^^^^^^^ 
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6:30 • 9:00 Dinner and Speaker Crystal Ballroom C 

Integrated Software Support Environments: Some Lessons Learned 

Frank Belz 

TRVy has developetl and applied several software support environments on several dozen software’ projee Is, with 
varying degrees of success. This talk will summarize the major lessons learned which distinguish the more successful 
environment applications from the less successful ones. These lessons learned will be related to a new research and 
development program in environment technology being conducted by the Arcadia Consortium. 


Thursday November 1 0, 1 988 


8:00 - 8:30 


Continental Breakfast 
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8:30- 10:30 SeSSlOH II Crystal Ballroom 

Some Lessons Space Station Software Support Environment 

Session Co-Chair: Everett Lyons, Project Manager- Session Co-Chair: lim Raney, SSE Project Manager, 

Software Support Environment, Lockheed Engi- Mission Support Directorate NASA/johnson Space 

neering Center 


Learned From an Ada Conversion Project 
Tim Porter 

Mr, Porter will present lessons learned from the development of Ada software programs to support large command 
and coritrol systems. The presentation will cover lessons learned about reusability, maintainability, portability, 
productivity and virtual interfaces from large projects. Special emphasis will be on the lessons learned from porting the 
SAVVAS tool to the IBM environment to support the development of NASA's software support environment. 

Mr. Tim Porter, Deputy Division Manager for Science Applicators International Corporation (SAIC), was chartered 
with the funding of the company's future software engineering environment. He has 1 5 years experience designing 
and developing command and control systems, software productivity tools, database design and managcriK'nl 
systems. He has specialized in the application of Ada and relational database technology to support large command 
and control systems. Mr, Porter has also focused on the development of reusable software to improve programmer 
productivity. 


Automating Software Quality Assurance 

Gokul Bhaumik 

Software quality assurance within an automated software development process control environment. New quality 
evaluation concepts utilize automated process management features of the system architecture for concurrent 
verification of design, the development activities and their attendant products for quality. 

Mr. Gokul Bhaumik is Manager for Lockheed, Safety Reliability & Quality Assurance (SR&QA), Software Support 
Environment System Project. Mr. Bhaumik has over 20 years experience in software lest and evaluation, software 
development, and software quality assurance assignments. In recent years, he has focused on the application of 
modern software engineering technologies and practices to the quality assurance process. 


SSE Tool Interoperability 

C T. Shotton 

How to make heterogeneous tools work together. 

C. T. Shotton is Technical Director of Planning Research Corporation (PRC). Mr. Shotton has been concentrating on 
using grammar based technology to solve software interoperability problems for over four years. 

10:30 - 10:45 Break 
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Next Generation 
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Professor, College of Engineering, Boston University 
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Computer-Aided Software Engineering Environments 
tor Real-Time Systems 


Crystal Ballroom 


Large, complex, distributed systems with oDerafinn^l To” • 

non-stop and mission and safety critical ?MAsn to support 

challenges that can not be safely or components pose life cycle 

models, methodologies, and tools that somptim ^ with the traditional 

applications. Furthermore thesp rh;ino suffice for smaller and simpler 

three environmennhostteratbn"®^^^^^^ 

control risks. This session wi« S ‘r f“‘^P‘^bly reduce and 

each of the three environmentr in 


rv . o ^ P*nel Chair and Moderator: Charles W Mckav 

Panelist: Miguel A. Carrio, jr. 

M, c ■ !h Technology Programs, Teledyne Brown Engineerins 

requirements analysis and the partitioning and aHocItbnTth cycle- systems 

operational interfaces. ‘^ese requirements among software, hardware ^d 


Panelist: E. Douglas jensen 
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4 : 45 - 5:15 


Closing Remarks and Wrap Up 


Crystal Ballroom 


6 



Keynote Address 

Software Development 
Environments: 

Status and Trends 

Larry E. Druffel 


(NOTES) 



8 



RICIS Research Review 


Charles W. McKay 
Peter Bishiop 
A.Glen Houston 
Terry Feagin 
Glenn B. Freedman 


PWK«>iN« PAGE §LAf4K NOT FUJWED 




9 



10 



Computer Systems and 
Software Engineeing 


Dr. Charles W. McKay 


PWIC»rHN« PAGE BLAf^K NOT 


f m _ mm 


11 



12 


Computer Systems and 
Software Engineering 

Charles W. McKay 
SERC @ UHCL 


Technologies Laboratory (HTL) was established in the 
^ University of Houston Clear Lake. Research 

onducted at the High Tech Lab is focused upon computer systems 
and software engineering. There is a strong emphasis on the 
interrelationship of these areas of technology and the United 

^ ^ January of 1987, NASA Headquarters 

announced the formation of its first research center dedicated to 
software engineering. Operated under the High Tech Lab, the 

Research Center (SERC) was formed at the 
University of Houston Clear Lake. The High Tech Lab/Software 

Research Center promotes cooperative research among 
g rnment, industry, and academia to advance the edge-of- 

state-of-the-practice in key topics of computer 
systems and software engineering which are critical for NASA. The 
J^ecqmmends appropriate actions, guidelines, standards, 
^? 4 - matters pertinent to the center's 

of the research conducted at the High Tech 

Research Center have given direction to 
many decisions made by NASA concerning the Space Station Program. 

research involves the investigation of computer 
U 1 ^ software engineering concepts, principles, models, 

environments. The relationship of this 
complex, non-stop, distributed systems is 
continues in the areas of reusability, data 
distributed systems, and the Ada 
Ik programming environments. Some members 

the High Tech/Software Engineering Research Center Team are 
members of tJie_ARTEWG (Ada Run Time Environment Working 
founded as an international task force to 
standardizing the interface to the Ada Run 
Time Support Environment. Team members currently chair the 
1 tributed Ada Task Force and the Subgroup responsible for 
evolving the Catalog of Interface Features and Options. 

High Tech Lab/Software Engineering Research 
center worked on a major project on reusability with Martin 

support from STARS, AIRMICS, DOE and 
This project involved developing a 
conceptual model for reusable Ada software that spanned^ the 

r JS^abilit^^ auTd°e1^^ and target environments. A 

reusability guidebook is to be published later this year with 

entltlert'^rn'irt participating organizations. it is 

for Bda Reuse and w>.tr<ca The High 
Tech Lab/ SERC has participated with MountainNET, Inc. on a related 

-P°n=°red by WTO? 

Tran«?fi:ai^ i, establishment of an Ada Technology 

Transfer Network, known as AdaNET. AdaNET is intended to; be usid 


m 


u 
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reusable products and processes across the life 
cycle of ;^a based projects. The repository will be accessible to 
public and private organizations for potential use in the 

Hi|r TeS “^T/SERC ■ on working with the 

nxgn lech Lab/SERC on a project in reusability Ford 

lib?a??!"® procedures for support of a reusable sl??warS 

SofTech, Inc. has worked with the High Tech L,ah/qottwf.r-r» 
Research Center on many projects. Several "of these 
IZ Station Program and thfuS o? 

vSificSon and^ engineering, systems integration and 

^ i Information System technology has been prevalent 
in the center's research. Studies have been conducted^ 
understand ^e important evolving Ada standards, guidelines and 
policies. When necessary and appropriate, the center ha*; erniirrK^- 
to influence these standards to reflect the best i^tLelt of the 

.eel'® •. P'^°9ram. Research in the area of nhltlLvel 

security has been conducted to discover ways to enhance the safetv 
of life and property in the Space Station Program. The nell lo? 
automatic verification tools for the Space Station Program haS 
also been addressed. Another area of research whichXr been 

i?eaS ^If ®its*'“Iffei"tv*‘^“ support software, particularly in the 
4 - +. • ^ effective use in embedded computer systems and 

esting and verification of flight software. The implications of 

SL "Studied expert and knowledge based systems have also 

Guidelines for extending the CAIS (Common Ada Interface Seti 
as a baseline for the System Interface Set of the Space Station 

Sgr“efh JI^WslRc'’°''witt'''‘”™®"^^ "r ^"''^^tigated through the 
nxgn -lecn Lab/SERC, with support from SofTech and Rockwel 1 

Honeywell, GHG Corporation, and the High Tech Lab/SERC have 

research in the areas of run time environmfan+-<= 

Together this team has worked to implement a baseline model with 

the distribution Of entities 
within Ada programs with tailorable run time environments llttt 
of the work has produced demonstrations of distributed Ada and of 

inLMctions*''Jith r monitoring and command bLed 

nteractions with the integration environment. The work continues 
to advance toward a bare machine prototype. 

the areas of object based information management 
systems has been conducted in conjunction with IBM. This project 
has focused upon identifying the key problems and promising 
syKem?^^ associated with the development and support^ of such 

Tech Lab/SERC and Inference Corporation studied the 
issues and approaches for developing tool support for integrating 

result in IPtelligence. The project is intended ?o 

result in an Ada-based, expert system generation toolset. 

For the next five years, the principle thrust of the; center's 
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research will focus upon a new generation of integrated systems 
software. The PCEE (Portable Common Execution Environment) 
intended to provide a common execution environment for 
Ada applications software and users. The principal domain of 
interest is large, complex, distributed computing systems with 
Mission and Safety Critical (MASC) components which require non- 
stop operation. ^ 


^5® j systems software is to be built in Ada, and 

supported by a heterogeneous collection of bare machines. The 
goal IS to provide systems software which is tailorable to the 
a variety of applications, while insuring that 
performance, fault tolerance, security, extensibility and the 

stop operation are satisfied. The intent of 
the object based approach is to create an appropriate run time 
kernel with catalogs of interface features and options. These 
features and options allow tailoring of system software interfaces 
to the specific requirements of each application. 

. designing the underlying implementation as a set of 

integrated modules, unnecessary redundancy and conflict among the 
various subsystems can be minimized while support for performance 
robustness, and security can be enhanced. Furthermore, the 
complementary features and options of the underlying subsystems 

non ability to support MASC components in 

non stop, distributed, and embedded applications rather than a 
more benign, general purpose programming environment. Examples of 
applications which would benefit from a PCEE include 
the s next generation of air traffic control software, the 

Space Station Program, the next generation of C^i systems, and the 

control and flexible manufacturing 
systems. The High Tech Lab/SERC is currently working on a project 
with GHG coloration to investigate the use of Ada in dilt?Ib2?ed 
and fault tolerant real-time applications. The PCEE is beinq 
proposed as a standard interface for this project also. 

The High Tech Lab/Software Engineering Research Center 
strives to advance the edge-of-knowledge and the state-of-the- 
practice in computer and information technologies. Working 
together with dedicated researchers from government, industry, and 

center continues to make important contributions to 
some of the most critical research areas of today. 
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Peter C. Bishop, Ph.D. 

Space Business Research Center 
University of Houston-Clear LaXe 
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Research Review for Infonaation Hanagenent 


Tne goal for Ricis research In ■{n^n'ras^-' 
management is to apply currently fvfifai?” 
technology to exlstlnl pwW^s^inni^^ 
tlon manageaeat. Research projects inofval 
the space Business Research Center (SBTC? 

Management Information and Decision sunnorf- 

technolop transfer netlorh ?lr lo?l«J|*’ * 

anI^"riort ““ P'^°9'“"tlng language; 

JL o * designing a communication system 
for the space Station Project Office at jI? 

‘l" Of all projects ll lo lsl 

work more 


institu?e?s "inaigurl? S^posTur^'ln 
RICIS coordinates research for jSc 

synthesizes and analyzes the results "fVs?rregl”°a*?vaX\"e"^"" ' 
ReseaJcher^Tn el/ management . 

can be used to increase prodL?l^!tf our°”"^V°- 

currently available technology to existina 

management. Jsc, like anv other ^ ^ problems in information 

proving ground for such appulJtioll “’^^anization, is a wonderful 


Space Business Research Center 
protoSpl''opera‘'tTcn oV’'the''°SpTcV\usTnesf 

Center emerged from the Space Market Mortei Center. The 

August 1986. The Project III vitiated in 

information businesses need to mak^ types of 

prospects of space. decisions about commercial 

the cl"nfer’'?ocated"?To\"^?l„7o™*t^ =i"Ply. 

from the media and the scientific fnd space, especially 

une scientific and technical communities, we 

did not find as much Information about business activity i,i space. 
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did not find as much information about business activity in space, 
but we did find people who wanted it. 

Figure 1 shows an analysis of the groups we interviewed to 
bheir need for additional space business information, and 
their ability to pay for such data. We concluded that the two 
groups most likely to use additional information were the service 
businesses and government agencies that facilitate the 
commercialization of space. 


Figure 1 
Comparison of 

Information Needs by Sector 




INTERNAL 
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Low 

High 
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Low 


High 
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During Phase II, which started in September 1987, the Center 
distributed space business information to any business person or 
U.S. government official who requested it. The Center had 
approximately 30 clients monthly and handled more than 400 requests 
for information during the ensuing year. The shear volume of 
information requests confirmed one of the results from Phase I — 
that the business community wanted additional data about space. 


^ Figure 2 shows the Center's client-profile. As expected, the 
business service sector accounted for 50% of the requests. The 
next figure indicates the types of information clients requested. 
Directory information, 38% of all requests, was the type more 
fre(^ently sought. The business community wants to know who is 
active in space business, and who the potential clients and 
suppliers are. Economic statistics on the space industry in 
?oStinely^”^ respective markets were also requested 

The Center is still taking requests for information, although 
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their frequency has diminished. On July i, the Center 

started to charge, although at a sublidi^d 
research. The rate of requests, predictably il ioSer 
han it was when the information was free. However we still rf»r-o^v<a 

that businelsIJ nol nell 

information about space, but are willing to pay for it. ^ ^ 


Figure 2 

Number of Contacts by Client Category 
February 1987 ~ April 1988 



Number 

Percent 

Academic 

35 

13% 

Business Service 

138 

50% 

Government 

47 

17% 

Information Companies 

14 

5% 

Large Aerospace 

10 

4% 

Media 

6 

2% 

Miscellaneous 

7 

3% 

Small Aerospace 

17 

6% 

TOTAL 

274 

100% 


Figure 3 


Number of OuesUons by Oueelion Category 
F«be7-AprM.N-4n 





- uy vuescj.cn Category 

February 1987 - April 1988 ^ ^ 


Category Number 


Directories 

Market Studies 

Government Contracting 

Space Technology “ 

Documents 

Law and Policy 

Economic 

Education 

Miscellaneous 


151 

_62 

49 

"44 

38 

22 

15 

7 

23 


Total 


20 


411 



• « The Center has established two other methods to disseminate 
during Phase III. The first is a publication program, 
launched in August with release of the booklet Space Businpg^ i qr» 
an economic profile and executive summary of the space industry 
public's response to the publication has been very 
gratifying - the Center sold more than 100 copies in the first 
™oi^th following its release. 

^ The second method of information dissemination is the use of 
seminars for the purpose of education. The Financial Aspects, nf 
th e gpaqe . Industr y was the 1st seminar which the Center co- 
sponsored with the Houston Chapter of the Texas Society of 

The seminar was very successful. 
It attracted forty Houston business professionals who learned some 
technical aspects of financing and controlling space 
ventures from people who are space business veterans. 

The Center is poised to become an autonomous and self- 

center for space commercialization. In 
offering research, publications, and seminars, the 
Center also plans to provide an on-line retrieval service for 

transportation vehicles, 
and satellites. Proposals to start this prototype service and to 

se^ices are currently under review by NASA. 
To date, the Space Business Research Center has successfully used 

businesses productively disseminate information to 


Management Information and Decision Support Environment 

RICIS has supported two other research projects to help JSC 
manage information. The first is the Management Information and 
Decision Support Environment (MIDSE) . MIDSE is a research 
prototype of an information environment tha^t will enable JSC 

efficiently access information in 

JSC's databases. 


Strategic Plan for Information 
Systems , identified a key problem. While the operational 
databases at JSC were well developed, managers and other employees 
could not retrieve information quickly or easily. The report 
recommended that access needed to be improved. report 

MIDSE is the RICIS response to that need. Briefly, the 

w hinges on a common user interface for all 

MAD2 databases on the JSC Center Information Network (CIN) . 

M screen of that interface, the Johnson Space 

Center Management Information System (JSCMIS) . The interface uses 

technology available . with the N0MAD2 
programming language. The interface also operates according to the 
best principles for the human use of computers, specifically; 



the new mainframe window technology available with moms no 

programing language. The interface also opelatL accordina to^hf 
best principles for the hunan use of conpute?s7 

. users can select input parameters in the order that best 
suits their job needs; v.-«-uer cnar oest 

■ f uP/ not only with information to help 

he interface, but also the database itself; 

■ details and presents them on 


can see the results of their selection*? p,i™no+- 
immediately, and modify those selections as they iish; 

’ '^itter?^'' retrieve it 

«il° bfported^^r to f speS?2i 
Art interfaces to be constructed in the DBMS • s own 

4GL and have the same operational characteristics” 


Figure 4 


— Management information System 

=Hain====»=============.-==IZ””~~~~“7 ' Version-0 . 8- 


APPLICATION name; 

REPORT name : 
FORMAT name : 
CONDITIONS name ; 


Function Keys 

2; Clear 3;Prev 5 .-Modify 6: Delete 9: Save 10: List ENTER: Proceed 


Visual Interface 


A second RICIS research prototype is 
information management of JSCs photograph's 
archives. JSC is the repository for all still 


helping with the 
and film i footage 
, film, video and 
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®= i’'® ®i®® increases. Dr. Mark 
vel^ to riea? “"i’'®rsity of Texas at Austin has worked the past 
design an interface specifically suited to this an<i 
similarly large repositories of visual mat«ial 

on thruse’S'worH=^*"^o*'®F retrieve Images depends 

f ^ words. Captions and/or keywords are assigned to each 

alnc^lstio° particular image enters Le or more 

assddlated terms), and the system retrieves 

not weak point is that linguistic symbols (words) do 

“ IS?;bUsrsea?lh''pfraSeiLf“ “ 


Of the" im®a;"'?tsel?''frf s'^arch" loot'"^n" thfs" wa"y?"!K^^ 

th^Lg^and mor°e'' p®re1fi^e^^^ ^“ages, and searphes can be more 

braanization^ potential application in any 

organization that maintains collections of imaaes inciuriinrr 

ageno“4 "%hir?s"^Inoth"®' P"‘’\^“tion houses Ind' governLnt 
Inteliiaentlv example where existing technology, 

must^mantoe^bnt?fV,ft ' P*^essing problems for those who 

productivity, (see Rlf^fncT^^^^ " to obtain high 


Reports 

research^DroiecL^'in^^''i^ describe all the current major 

detail information management at this same level of 

woSd'iike^tTme'ntio™" significant reports, however, which I 

hie • Chris Dede reported the preliminary results of 

systems'^ i^° the Soace'^st^t- ^^w knowledge-based documentation 

a^ri^now avail has been published 

Report alL wac ■ ^^^t^^bution . (See Reference 2 . ) The 

hypertext and hvnfi>-n,c.H ■ ^ national RICIS conference on 

yp rtext and hypermedia, co-hosted by Dr. Dede in September. 

capabiliti^?^of js‘?^a^nd survey of the computing 

report last Spring. (See Relerence" 3 . ^^he^^epoVt^Sont^i^^^^ 

comp?eLnsive^is?^o^ software used locally, and a 

this censusT aerospace contractors who contributed to 


a 


Dr. Robert Mayer of Texas A&M 
formal methodology for software 


continues his work to develop 
requirements analysis. We 
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spring. 

W ?® Center for Space and Advanced Technoloqv has 

RICIS actWltv final phase of their 

RICis activity on the commercialization of the U.S. International 

Space Station. The first report analyzes the forces and factors 
that will promote or inhibit space station commercialization. The 
second report scrutinizes the potential for biotechnology in space 
The biotechnology study includes the results of an indiStry sSrvey 
indicating that the commercial potential for research in space is 
higher than anticipated. (See References 5 and 6.) 

studies are available through the 
through the Space Business Research Center. Also 
their principal investigators will be happy to discuss their 

projects in detail with individuals who would like additional 
information. 


Next Steps -T-- . 

Most of these projects will continue into 1989. i expect to 
additional results at this symposium next Fall. _ in 
addition, the Space Business Research Center is working on two new 
projects in information management. 


4 - w first of these is the AdaNET project to develop a 
technology transfer network for software engineering and the Ada 
programming language. AdaNET is funded by the NASA Technology 
utilization Office with the assistance of other governfneRt 
agencies. Most of the development work is being conducted by 
MountainNet, Inc,, a West Virginia based firm. The network effort 

transfer knowledge, experience, and 
artifacts - from government projects which have used software 
engineering principles and/or the Ada language - to the private 
sector. A central goal of the research is to advance an 
understanding that software reusability is the theoretical 
foundation for the next generation of software repositories. 
AdaNET is a main RICIS project, and I expect you will hear a great 
deal more about it in the coming months. 


Another information management project was started last August 
for JSC's Space Station Project Office. The project entails 
designing a communication systems to let office managers 
communicate the status of their work to each other and to the 
project manager effectively and efficiently. This deceptively 
simple requirement, however, has become a problem of enormous 
magnitude in today's world of la^e scale projects spanning' long 
time frames. The Space Business Research Center is working with 
Department of Decision and Information Science at the 
University of Houston to help build the system. 
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Conclusion 


these projects have the same central aim - to use 
xnformation technology to help people work more productively. 

change as we make progress in many ways, lilt 
much'reLtit goals. This year, we report results. However, 

Sfour^c^Smp^LhLn?"?- — 
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ABSTRACT 


the'^Tas^™ Tr ""fir ’"arti«oiaY°intMli"'®"''® 

uSda™fr^oT^’'cnly^''r^ihort^''t-’'°^®'=H® have^beSn 

progress within the areal has been ‘’"t 
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RICIS RESEARCH REVIEW OF 
ARTIFICIAL INT|:^IGENCE AND EXPERT SYSTEMS 


of ^artmc'ial^intJn^ accomplishments in the 
are summarized below ^ systems 


Spert sJstemrstSL^ ^9°™'^»^cations and Tracking 
at"^ the "^^^n?versftv o^f ^^°nducted by faculty 

involves the ditelooSfn^ ? 

software for the support °of ^Sult' det^°?^^®^ 

isolation, and recoverv detection, 

communications and f^om failures in the 

station. As a ?Luit Of 

method for isolafin^ / work, a very fast 

failures in the svste™^ and two-point 

Simulators for testina developed, 

developed and used ^tr> software have been 

Distributed exoert evaluate the system, 

and <^evellped“"o\^^o7K^‘rth?ri«if° 


Simu^tL a°nl‘'\ei?°"^'lsTon to 

Applications) is unde^^^^ Space 

During the fiT'<?+- Ric& University. 

seen the development o°/ project has 

testbed and physical modli^ P^®^^®inary graphics 
to permit comparison wfth ?h. ^ *1®®” constructed 
graphics testb^^d hil graphics models. a 

workstation to pe^aYt alVlr- ^ Sun 

direction with ^arav light source 

Physical modSs ^ in^i ,fd ^ Gouraud shading. 

atLchment devices ^ cylinders and 


culminated at the University of 
plannina for T-r>Hr»+-T/^ PJ^oject involved path 

code encapsulation and \1?to'’:a\"fng ihfproclsf!’'®^^’’ 
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^nother project, underway at Massachusetts 
Institute of Technology, concerns the development 
and application of fuzzy sets and related theories 
® ^^ilure detection and control in space systems. 


A project currently being carried out at Rice 
University involves the demonstration of a 3D 
vision algorithm for space applications. The 
research concerns developing object recognition 
algorithms that are insensitive to object 
orientation and distance. 


At Yale University, the use of the T programming 
language on the Cray X/MP is being investigated. 
The language, a superset of Scheme which is a 
dialect of LISP, is being ported to the Cray with 
an eye toward making use of parallel computation. 


P^oj®ct, carried out by Lincom Corporation, 
involves research and development for onboard 
navigation and ground-based expert/trainer system. 


Object-oriented programming systems (OOPS) and 
frame representation schemes using Ada are being 
_hy Softech and Brown University, The 
possibilities for^ merging OOPS and Ada has been 
pursued. The merits and demerits of OOPS as a way 
of addressing the applicability of OOPS to various 
programming tasks has been investigated. 


^ ^^ivarsity of Lowell study is underway regarding 
a unified robotics control system using a parallel 

goals include 

Identification of enabling and enhancing 
technologies for space operations, and the 
application of emerging technologies to problems in 
space and planetary exploration, with particular 
attention to ways of increasing computational speed 
via parallel processing and expert systems. 


The last project, underway at Rice University, 
involves the development of algorithms and software 
for the recognition and location of single 
unoccluded objects based on fusion data from a 
single camera (intensity image) and from a laser 
range imaging device (range image) . The algorithm 
^isd^iniinates the objects from the clutter and 
obstacles in the field of view. 
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onfv these projects have been in progress over 
y a year or two and most results are only of a 
nature. Nevertheless, it is apparent 

resLrch®ha°7®^^^^ progress within this area of 
^ steady and worthwhile. Several 

^eS^resul^rarf fSJ?^^oSg^ objectives already and 
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Research final 


mathematical and statistical analysis 


Of RICK il to research component 

statistical techn?ies fof aeros,S.cl »>atha»,aticaT Ind 

specific research a«al of interest i^fclud\''*'"^"^ applications 
experiment design, reliability assIss^ira^r^SL^^fi 

Research Activii-i^g 

Kt‘?*T4^^’“l''^"'^^ata«sticar"anaT^^^^^ activity in 

entitled "Space Station Momen^nTn research activity is 

and referred to as MS.l. This ?eISrch 

Guidance and Navigation Branch ce hh sponsored bj the 

Analysis Division within the "lesion Planning and 

NASA/jsc. The NASA tLh^ilal moi?? S“PP°rt Directorate at 

aerospace engineer in thi ciKence » ^ f ?-® “avid Seller, an 

Clear Lake technical repre/e„^^^^^^ TheDH- 

profesEor of computer science. ative is Dr. Terry Feagin, 

directim''‘'of Dr"!®^ Bl,ng°"wie*' “as^Jist ^*t 

cl??^^:i2^ga°tors"?n?lude =n9ln^ee°ring “Sechanics" 

Hull, professors from the Xiie department “avid c! 

assistants also support this activity. * graduate research 

th?ee-year"^periSy^ initiated February i, 1987, for a planned 
adaptive'^oontirSl tecLi^fs ftr‘"uie*’'|^°'’ fault-tolerant 

Station Program needs a’^ontSl ^v^te?®,Sf• “<=ation. The Space 
modular construction of the accomodate a 

stabilization over a wide PP°''i'^s attitude 
^attribution, which will occur du?ina the mass 

follow-pn configuration orowth the initial assembly and 

developing fundamental concepts a? wJll ^"^^^^^tudy focuses on 
techniques for designing a roLst adaptive conteoT^ysteS?'''*^^^ 

momentul°'and‘^ttMttdt"tOTtttl lltratltL tl'*® '^^velopment of 

guidance, navigation and control ^omnuXr-^^ 4 -^^® Station's 

the momentum and attitude control system, in particular, 

accomodate both small and large stat i on °”f 4 - been modified to 
attitudes (TEA'S) . The new control torque equilibrium 

modifications were quaternion 

station navigation computer is T i ^ since the space 

infoCTiation in quaternion form anH provide attitude 

required to maintain large pitS^TEA's. station may be 


WGE BLANK NOT FMJMSD 




35 


As a '.result of this investigation, a significant, new feature has 
also been added to the controller. It now has the capability to 
seek a dynamic TEA. This is a time-varying torque equilibrium 
attitude that virtually eliminates control moment gyro (CMG) 
momentum occilations. The new feature plus the above 
modifications greatly enhance the overall usefulness and 
flexibility of the controller. 

Other accomplishments include the development of algorithms for 
identifying station mass properties including bending modes and 
frequencies. 

In the coming year, plans are to continue the study and 
development of adaptable control equations and identification 
algorithms for the Space Station GN&C flight computer; attempt to 
define robustness measures that are meaningful for Space Station 
momentum management control systems; investigate techniques for 
establishing the inertia bounds in which the station will remain 
stable; and determine the optimum gain selection technique for 
the momentum management controller. 

Future Plans 

For some time, we have been attempting to initiate a research 
activity related to software reliability modeling. During the 
past year, exploratory conversations were held with members of 
JSC's Safety, Reliability and Quality Assurance office. These 
discussions have now led to a potential relationship between un- 
clear Lake and the Safety Group within the Boeing Aerospace 
Company. 

The plan is for UH-Clear Lake to lead a project to establish a 
quantitative risk analysis methodology for the software portions 
of Boeing's , computer-aided user-oriented system evaluation 
(CAUSE) hardware and software analysis model. The intent is to 
automatically generate detailed fault trees from which single and 
multiple failure points of systems (due to software) can be 
identified and analyzed as a part of the risk analysis process. 

In support of this project, a workshop is planned to be held in 
the coming year. Experts in the field will be invited to 
participate and discuss the issues in modeling software 
reliability. 
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■ education and training 

range of actititiM“spoMoredX‘'th^^ supports the 

particular, this compoSInf agree^^ent. 

transfer, information transfe^'^^naa® research in technology 

Softwa«*'Englneriin^ Pr?fesLlona“^^ formation of the 

assists all Ricis researlhIJs tnd (SEPEC) . SEPEC 

nferences, seminars, and technoloav . ®P®^sors through its 

also assists all rtptc ^ecnnoiogy transfer activities avnvn 

programs and affiiiatfons ^iltr’^var-^ coordinating cooperative 
and^.evelopment in software engl^efrr„f 

oducatlon^andTraiSng^arel'^that^wJ" research activities in the 

past year. in this^ resea begun or completed during the 
reviewed in the temporal order in w1f7ch®'t'w a<=tivities will bj 
the title, sajor points s?atus®La®a^^•“"''®‘'• each 

follows: -• pwincs, status and deliverables are as 

^ training sys t em /nnatpo^ 

Completed by SofTech t«/^ a-i. 

System (CBATS) was develonl/?h^' the Computer Based Ada Trainina 

k ; •" “ "ffi 

f, ( 

CBATS used hvuei'tevh t 

manual, syntax examplesrAda and so?tL^e '=''^ reference 

and commentary i„ a straight information, 

™tltl ®I"*°®°fTloh‘' rlsSlted'' l?‘'a''®fie®id*'?rrr management, 

??titled -Software Englneerlno- tield-tested , three day cours4 

Mas.-- •?^aeeg{ «gS ?Ba ^ 

Completed in October 19 rr -i-vici 

Der, 1988, the course is now available. 
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3. RESEARCH IN INTELLIGENT TUTORING SYSTEMS FOR KNOWLEDGE POOR 
DOMAINS 


This project is sponsored by the US Air Force Human Resource 
Laboratory at Brooks Air Force Base. Working with the Artificial 
Intelligence section and flight training branch at NASA/JSC, as 
well as UHCL, this project will provide a prototype tutoring system 
for the Mission Operations Directorate to use in training personnel 
to use the flight control panel, a task that retjuires coordinating 
a knowledge base, with automatic motor skills, auditory and visual 
overload, and a detailed understanding of flight data. The work 
for this project is being conducted at Southwest Research Institute 
in San Antonio. 

4 . SOFTWARE ENGINEERING EDUCATION AND TRAINING IMPLEMENTATION 
RESEARCH 


This research activity will result in new training tapes for 
NASA, featuring the latest available information on design 
strategies in support of Ada use. In addition, the activities 
supports maintenance of an education and training database for 
courses, resources and services. The activity fosters the 
dissemination of research information on software engineering. 
Sponsored by the Mission Support Directorate, this activity focuses 
primarily on space station applications, intended for the 
deliverables. 


5. PROTOTYPING CAPABILITIES FOR MISSION OPERATIONS DIRECTORATE ^ 

This activity provided access to the Mission Operations 
Directorate to use the facilities of the Advanced Technology Center 
for training and research purposes. The activity is on-going. 

6. HYPERMEDIA TOOLS FOR BUILDING TECHNICAL TRAINING SYSTEMS 

This activity, sponsored by the US Air Force's Human Resource 
Branch Intelligent Systems, investigates advanced knowledge 
transfer technologies and their application to future training 
systems. The research is to be conducted by Dr. Christopher Dede 
and will be directed both to Air Force requirements and those of 
NASA's space station training offices. 

As the project has just begun, results will not be available 
until late 1989. 

7. MICROCOMPUTER INTELLIGENCE FOR TECHNICAL TRAINING -PHASE II 

This project features a continuation of work developed by 
Search Technology for the US Air Force and NASA/Mission Operations 
Directorate. The project will build on the initial product of a 
rule-based system to teach shuttle fuel, cell understanding through 
sophisticated simulations of malfunctions. The second phase will 
extend the capabilities of the system and add an authoring system., . 
The second phase has just begun. __ ‘ 
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assists all other compone'rS^throu^ training component of Ricis 
research on innovative sys4ms^ and information, 
in education and training settings advanced technology 
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Requirements Analysis, Domain 
Knowledge, and Design 

Colin Potts 

MCC Software Technology Program 


Mggesw: domain modeling ami “v® am 

Domain modeling is ,he rSreaemt™ f henristics. 

requiremcnls specification. Anificial inlell.Ve'™"' ‘”'1““" ‘“'O'vWge prior to 
applicable for domain modeC“^ T S ‘ r"“ 

moileling lechniqnes. such as that in len ^n 
heuristics are re^o^nin^^ 4"“ t 

generate questions of clarification or "^“i^ments. They usuaUy 

heuristics can be repressed completeness. Analysis 

ftamework. This is illusuated by an issue'^bS^'^?*^^ “ an issue-based 

and fucntional specification ^ Th^v ‘domain modeling 

^ ; J^iitatary design of simp, e emtS sysSnT 

Introduction' 

»«ae in man, Urge syaem development projects ^HTf T "’““'"'a are 

qnmtmenls. and the lack of applicadon dlain n “""''“"8 ce- 

Iscoe and Krasner. 1988 ). In this paper two improvemet “I oiganization (Curtis. 

am suggested: domain modeting.and thesystem^^^ -alysis pmctice 

The Role of Domain Knowledge 

^mlly during its early “Retime, es- 

ments arc particularly sensitive to changing requirements A« • ^ functional require- 

ments added the logical basis for the design ^hitec^n^/rir^^^^^^ "T" 

ay DC lost. To make a design less sensitive 
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to changing requirements, one could base the design on anticipated as well as existing requirements. 
Unfortunately, it is hard to anticipate requirements. 

An alternative is to base designs on a model of the ap^cadon domain. A domain model contains 
the objects, relationships, and concepts that are considered important to the users. It is likely to be 
more stable than the requirements, because the domain evolves more slowly and less significantly dur- 
ing the lifetime of of a system than its requirements. 

There are other advantages to formulating a domain model before specifying the requirements in 
detail (Bruns and Totts, 1988): twns and concepts delTried^n a domain rnodd can be used with less 
risk of misunderstanding; domain knowledge may be shared across projects; the activity of domain 
modeling acts as a goal-directed familiarization activity prior to specification; ^d, the existence of a 
domain model may improve the training of new developers and maintainers. ^ ■ 

The use of domain modeling in software design has been proposed before. Greenspan, Mylopoulos 
and Borgida (1982) give a good overview of the domain modeling approach to software development, 
and why it was felt to be necessary in the TAXIS information systems design project: 

In considering the development of a variety of information systems we have found it 
necessary to become initmately familiar with a wide range of subject matters: 
medical knowledge, hospital procedures, available therapies (drugs, surgery, etc.), 
legal responsibilities to government, and so on. We believe that this kind of real 
world knowledge needs to be captured in a formal requirements specificatmn. 

A valid domain model can only be formulated by people with sufficient knowledge of the appli- 
cation domain, but this runs up against the relative absence of domain expertise in most development 
projects. One possible long-term solution is to apply artificial intelligence techniques to require- 
ments analysis. Intelligent requirements analysis tools are envisaged that will be able to use deep 
knowledge of the application domain to question the analyst about possible inconsistencies or gaps in 
the stated requirements. Some promising research is underway (Fickas. 1987; Rich, Waters and Re- 
ubenstein, 1987), and ultimately the problems of requirements analysis may be addressed by these 
means. A recent review of domain modeling approxhes (Bruns and Potts, 1988), however, concluded 
that the most effective applications of domain modeling in industrial system development to date 
have incorporated restricted modeling primitives, modest goals, and a systematic method. Examples 
of such restricted domain modeling approaches include JSD (Jackson, 1983) and Booch’s (1987) object- 
oriented Ada design method. — 

Systematic Requirements Analy sis 

A s^ond majea' problem with requirements elicitation and analysis practices is tfieir unsystematic na- 
ture. To some degree this is unavoidable; requirements elicitation and analysis are inherently open-end- 
ed. Much can be done, however; fcff example by using diagramrnaTtic^ t^ such as CORE 

(Mullery, 1985) to incr^e confidence in requirements consistency. Another place where greater con- 
trol could be exercised is the interface from requirements to design. Better practical techniques are 
needed to ‘graft’ requirements onto design specifications, particularly in view of the inevitability of 
changes to the requirements once the design is underway. If this could be done, it would have the bo- 
nus of improving traceability: that is, the ability to be able to demonstrate that every requirement is 
satisfied by the^deSgh" 
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Making requirements analysis more systematic is also a eoal of th. Ar 
But again, a short-term partial solution o, o i k. c ^ ^ research mentioned above, 

checks can be represented in a systematic and mac^ requirements analysis heuristics and 

work: the issneboseCConklin and 

JSD as an illustration 

Next, the systematic, issue-based nature of its ■ t- • -n modeling are discussed, 

ihc method arc discussed; the heuristics that det heuristics in two phases of 

and d« hen*,ics .n.. gu 7 « 71 “ “>» Oo-ain „.„del, 

:ta‘rr„r„— 

a. i«na..d .. ,SO . .. pal.. <Becan. “X— etr 



Figure I: 


JSD £SS"SId hSfc^ shSli^ 


precedes specification. 
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tomers to the implementors, only forward flows are shown. This does not imply that feedback docs 
not occur.) _ i_: . 

JSD Ts only an illustration of how systems can be specified and designetT when greater emphasis is 
given to domain modeling and systematic analysis. JSD is not universally applicable, nor is it perfect 
wh^e it is applicable. 

The Development Method JSD 

Although Jackson does not describe JSD this way, JSD consists of two major phases, specification 
and implementation, each of which involves a series of steps. The strategy of JSD, the major steps and 
their rationale, is described in this section, and the tactics, or modeling heuristics locally applicable 
within the steps, are illustrated later. The product of the specification phase is an opwational specifi- 
cation, which describes the desired functionality. It consists of a set of concurrent p-ocesses which 
communicate asynchronously. The goal of the subsequent implementation phase is to sequentialize the 
specification until an efficiently implementable amount of conc3rciTCy”remaTns. Only the specifica- 
tion phase of JSD will be described will be described further. 

The JSD specification phase follows the formula: 

System = Model + Function 

A system comprises a model of its environment and mechanisms to accomplish its functionality. 
For example, a patient monitoring system in a hospital niust include a model of patients and their vi- 
tal signs, etc., and operations that perfexm the required functions, such as sounding alarms when a pa- 
tient’s vital signs fall outside a safe range. A model is created by first analyzing the entities and 
events of the relevant part of the real world (in the ca« of a i^ent monitoring system, the real 
world is an intensive care unit). TTie resulting model contains a set of regular expressions, each one 
specifying the lifecycle of a real-world entity in terms of the actions it performs or suffers. An ex- 
ample is given as a structure diagram in Figure 2. A PAUDENT is ADMITted, MONTTORed and DE- 



Figure 2: A structure diagram showing the lifecycle of the BED entity 

of an intensive care ^ ^ ^ ^ ^ i; " : : ’1 
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TACHed in that order. The MONITOR ™rt tu i-c 

events, which may be a READ VITAL SIGNS a r * iteraUon of MEDICAL 

drug .Uo„, and » Z“ JT. IsD 7 

UCS and their properties that the system need^ fn ^ i ‘® restricted to only those enti- 

«lge to. may be aaefal .0 to developers is 0 ,^'"^"““ knowb 

needs u> model to paUenl. because it is required to nrrvt ** «. a patient monitoring system 

signs and to warn to nurse if any of tom^me stosocal summaries of a paUent’s vital 

gal responsibilities or htispital policy I” ^,7 “ *« "»■ "eed to model a nurse’s le- 

system itself is m,t mquirL » « La rtoTn^Tn - -ause to 

in scope than a domain model might be. owledge. ITius. a JSD model is more restricted 

a.ar;lg:“ ~ 

bis eaamples tot it is essendal to L Lme “ clear from 

iadgewbrnbenUdesarerelevantto to;srLmtobeTrer“ 

Once the requirements have been elicifP/i nnr» 
lions can be introduced into the initial model to cre^TT^ 7 ~ 

functions can be accomplished by augmenting existing ^ • *^®^**™ specification. Simple reporting 

to be eml,edded in the model. More cLnlex Wr These functions arc said 

iroduced that realit. the funetir^^^^^^^ - --e processes to be in- 

These funcUons arc said to be imposed on the m^od^TH^J*^^ by several monitoring processes, 
non diagram for the paUent monitoring system Therf ‘ T specifica- 

» - p.™. cuaty ^os r::: 
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rent PS value with constants symptomatic of »nsor disconnection or failure). This function can be 
embcddcHT n^lONI TOk PATIENT. The oSct Marm is activated when the" pmeii fs vlufl "signs 1^11 
outside a langc^defined by the DOCTOR in the input DRS. Since this function requires integration of 
multiple inputs from the environment, it is an imposed function and requires the introduction of the 

CHECK s>wctywo^s:^^^^ 7 /. 

Issue-Based Domain Modeling and Specification 

Before illustrating some of JSD’s modeling and specification heuristics, the issue-based framework 
that is used to represent it will be introduced. 

The Iss ue- Based Fram ework 

In the issue-based framework (Potts, 1988b), there are only five kinds of entities: artifacts (method- 
specific design documents), steps (revision, refinement or elaboration operations), issues, positions, 
and arguments. Artifacts (c.g. data flow diagrams) and steps ^e.g. top-down decomposition) are a 
standard COTiptment of all design methods, but the representation of reasoning and rationale in terms 
of issues, positions, and arguments is lessjEamiliar. 

The representation stems from Ritters work in using his IBIS (‘issue-based information sys- 
tems’) model to support the discussion of policy and design alternatives in architectural planning (see 
Conklin and Begeman, 1988 for a summary). Issues pose question s about some foc us of cmccm. For 
example, ‘iFfow can the heartbeat sensor failTn such a way that the laUeht^^'Mte appear threat- 

ening?’ is a domain-related issue. A position is a candidate response to an issue, such as ‘Heartbeat sen- 
sor failure mode F gives rise to apparently threatening vital signs’. An argument may support or ob- 
ject to a position. For example, an argument that supports the above position might be ‘Failure mode 
F ^jpaiently tpiadruples the heart rate because a masking error’, whereas an argument that opposed 
the position might be ‘Failure mode F can always be detected indqrendently by self-test procedure P’. 
Issues, positions or arguments may spawn sub-issues. For example, a sub-issue raised by the last argu- 
ment could be ‘Can self-test ^ocedure P be run sufficiently fast whcnevo- the patignt’s heartrate ex- 
ceeds X beats per minute so that it can be ascertained wldiih ajStorapeutically s^e interval whether 
Failure mode F has arisen?’ 

Issue-Based Reasoning in the Early Stages of JSt) 

Figure 4 illustrates a small part of an issue-based representation of the heuristics of JSD. Ignore for 
the moment the nwtwll)6xw, and consider only the heavy outer boxes. These represent the five basic 
entity classes of flic representation. Prom the names of die relations in Figure 3 it can be seen that 
sreps modify artifacts, issues review artifacts, positions respond to issues, and so on. Within the 
heavy outer boxes we see that — for example — JSD’s issues form a taxonomy of classes. Although 
positions in gener^ respond to issues, we see that only some JSD positions are valid responses to par- 
ticular issues. For example, the position sub-class not entity! is a valid response to issues of sub- 
class entity?, which address the question whether a c^didate entity is an entity in the model accord- 
ing to JSD’s modeling criteria. Furthermore, arguments of type not individuatable can support this 
type of position, whereas arguments of type not 0MB (for ‘outsiefe the model boundary’) cannot 
The legality of relationships is inherited. For example, any issue of type EA check, including enti- 
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Figure 4: 


Pm of the Entity Class Hierarchies for JSD with 
relauonships. 


ly? and actron? issues, can be raised to review the JSD entity-action list document. 

Example 

Whaher .h. elev«, need. „ modll - 

ly-actlon list (a JSD documem dial iacludra much <d teKDd^'^“i'T' “ 

is of a type iba, should always be raised coneemine Ja° mformation). This issue 

is a yesMo quesUon, d»te a^ two P^do™hLT^l“j;"L" 

not au enUty. aud the positiou that it is. To “ 

gram. Several arguments can be made- fr. ^ • y the selected posrtron is shown in the dia- 

U»™. of type 'u^ hS Lg^ ..r*.*» "Jr"® “““‘"e ” '"•‘•y fiom a JSD model. One of 

.n die model, because the system has no way of keep^rt.^ oh!h Tf “ 

to respond to requests, of course but it ha/nn ^ of rndivrdual passengers. It must be able 

mquem. or whi Zd 7 "*■ a 

whorequestedloEetolfatlhegLtKinoot. ’ "nor is the same passenger 

JSD^XmlarZ^'deln^ ctTae’':' t “■ 

.am am -- 
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Figure 5: Simple (PASSENGER replacement) design q>isode 


merit of which is shown here, is a netwta'k structured template. 

The preceding illustration is atypically simple and the reasoning is restricted to a small pan of 
the model. The topic is the content of the entity-action list, and the evaluation of a small numbo- of 
modeling criteria are sufficient for the exploration of the alternatives. Most decisions are more com- 
plex than that they range more broadly and necessitate more open-ended reasoning. Potts (1988b) 
contains a detailed example, also from Jadcson’s elevator system, of the reasoning behind the way the 
scheduling function is imposed on the initial model. This involves several interconnected analyses, ar- 
tifacts and sub-issues. 

As an analogous, though ablneviated account, consider the introduction of the CHECK SAFETY 
process of the patient monitoring system specification (sec Figure 3). The reason for introducing 
CHECK SAFETY, explained in terms of the issue-based fiamewotk, is as follows: an issue is raised 
concerning the requirement that a safety alarm should be sounded whenever the patient’s vital signs 
fall outside the doctor's specified bounds. The issue is how the requirement should be supported: by 
embedding inside DOCTOR MONITOR, or (more likely) in PATIENT MONITOR, or by the addi- 
Uon of a new imposed funcUon process. Many subsidiary issues wiU be raised at flic same Ume: for 
example, how are the bounds to be specified? how often should the comparison be made? are the 
bounds all single valued or can the doctor specify logical combinations of different vital signs? etc. 
The usual reason in JSD for introducing a process to suppwt a required function is that it must com- 
bine inputs from several monitor processes or other function processes. This is the case here. The algo- 
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of ■"orged data scream 

dwign qucsuons, but really concern the frequency and ordi* r ^ ^ 

ability of system responses to the inputs it receives To 

stream and the degree of fairness required of CHE^K data 

answci^. For example, how frequenUy should the CHECK UlSUT* need to be 

from the doctor? Should new criteria take efr . • SAFETY process check for new criteria 

tag a dc., . accapcabcr;:: “r rTa'I 

Conclusions 

cess more imixirtant early in die development pro- 

gued that a more systematic approach to Ztelnr" - 

framework is ureful for capturing the heuristic^f a meA^ « feas^le. and that an issue-based 

Other methods than JSD alco ii a illustrates both suggestions. 

^fication and design. Object-orient^ and sy,^„3Uc piocess in 

5^ ased on a similar principle; that a design should be d 1 different from JSD. but 

Stacemed methods (e.g. Hacloy ahfiSl ‘ 

mov^ away fem cop-dowa fmcccional decomposicioT’tol h 1984) have 

gy. n^l these cases, not only does the analyst strive to d ^ oa^side-m’ event-driven methodolo- 
HOT before specitymg the system’s toclionality but theT^™^ “™"- 

■"odel "‘■"dn-ajorimpactonthesabscoentpesi^p.^ “* “f >«„lcip8 ’domain 

Wile. °98™ and 

omering respichons cardinalio, *”“* “"a“a,nts (as opposed to 

-8 associated wid, relationships can be described id 1984). some of the mean. 

n e Requirements Apprentice (Rich et al 1987) doma^^k” « introduced. 

(Mul^. many analysis heuristics - CORE 

"■ay be eqmUly suitable for other prescriptive methods. aP«incally with JSD in mind, and 

T^e specialization mechanism aUows the simnif. 

live development method, or any application do^ • ^ *» customized for a prescrin- 

stood. Although it is conceivable that intelligent ^ su '^*'*^** modeling issues are well-under- 
base that corresponded to that of the issu^lS ""r ^ i-owedge- 

m me shori.,emt. ’The issnebased analysis of a me^'^dr* 

posed discipline when nsing die generipmpl^ 7“ =4 a tttanmtlly im 

purpose issue eaptopon tool glBlS (Conklin and Begeman 
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1988). 

it must be stressed that JSD has not been the topic of this paper. It is mly jyn iU^trajdp of the 
ways in which inform^ development methods that are based on sound design {xinciples can lead to a 
more systematic approach to ^ earliest phases of system develo pment The y c an do this in two 
ways: by encouraging the explication of application knowledge in a formal description of the domain, 
and by providing the analyst with a structured netwoiic of checks and heuristics. 
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-Abstract. We present a new software development paradigm that automates the 
derivation of implementations from requirements. In this paradigm 
mfomally-stated requirements are expressed in a domain-specific requirements 
specification language. This language is machine-understable and requirements 
expres^d in it are captured in a knowledge base. Once the requirements are 
captured, more detailed specifications and eventually implementations are derived by 
the system \xsm% tran^ormational synthesis. A key characteristic of the process is 
that the required human intervention is in the form of providing problem- and 
domain-spwific engineering knowledge, not in writing detailed implementations. 
We desmbe a prototype system that applies the paradigm in the realm of 
®.”Si*^eeMg: the prototype automatically generates implementations 
ot buffers following analysis of the requirements on each buffer. 








Introduction. Our goal is to increase software development productivity by automating the 
development process. We attack several weaknesses in current software development m^els: 


• lack of formal connection between requirements and code, 
emphasis on manual production of code, an error-prone process, and 

* inability to reuse previously-developed code. 


Our approach is to provide domain-specific requirements specification languages that aUow 
nwc^e-cap^ and rnachine-understanding of requirements in a particular domain. Next we 

that automate the generation of more detailed specifications and 
implenientations (c^e) from the requirements specifications. These compilers are also 
dqrn^-speafic and embody knowledge about how to genorate specifications and implementations 
m particul^ engineering domains. Thus the compilation process occurs in a knowledge base and 
generauon of code from requirements is expUcitly represented in this knowl^ge^ 
software development environment that we propose tracks design and implementSon 
decisions made by the user ^ well ^ Oiqse m^^^ by the system itself. Because the process as well 
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^ conclusions expressed in this paper are those of the author and 
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enviionnrem. REFINE has totSa? s™ development 

oTeSbk'tSKms^ficaS^ 

S?“£SS:“iS^^ 

synthesis. Barstow has writtren extensivelv on aevelopment by transformational 

[3] and the state of the art in transformational Droerammin^^rn^*^”n**^ programming systems in 
have developed a knowledeeSed ® Nonnenmann [5] 

specmcado^s tom 

^uteTOoB fs on programs tom 

captured in the knowledge base are analvze^anH r^finS j ^*^“’®™®nts that have been 

ex^utable code. At iSnSat^tSffhf.^ specifications and then into 

have been refined down to the code lewl and oUs thafhaJ<»^^ ^ ^uirements that 

but not fully implemented. Each^Sem sffiin^ elaborated 

refinement at each stage The comnutarinLi mrSi^i a specific feature selected for 

that take a partiaUy defSled piSff of applying transformation rules 

to which further tfansformatw^^rulL ® detailed structure 

into lower-level data types such S aS formation rules refine sets 

engineering and progr^Siming knoSe base Sh refinement is guided by the 
represents a desim decision Ld tiieSesSn ^ transformation rule 

enables the user to return to an earlier staaefn ^ raided in a derivation tree that 

previous design decisions Transformational svm^^f °rdCT to play out alternatives to 
generation (rIfine) a^d to successfuUy to program 

applications the synthesis process procSes entirely robotic vehicles. In these 

this paper, the process is interactive, witii Ae user sSw eS‘ Prototype discussed in 
system’s knowledge base is inadequate to identify TrefiSem. decisions when the 

'“■rfoTO'afcn mleS iS — 

faithfulness of the partial refinement to the^^uirements’*^^ rofined set of requiremenB preserves 
transfoimation rulS7KoTens“.^ .‘^"““'“rPmservation is a p V«y of 

needs to be ensured only 

traditioi^ approacCfS°as usi^riSbrouSi Programs with 

generally appUcable than knowledge encoded iMhrf^ofpJt^mr'”’ f" 
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implementations of these specifications For PYar^iV compiler automatically generates 

implementations Gists compiler generates low-level dam type 

implenKnatiSIs ??■ “ “ '>’= aPP^Priate ^ 

among sets, etc. Customer experience over the VearSore'^Si?'™*T^^^^ 
order-of-magnitude productivity gain writing Rp™ J^?r^ of REroffi use shows that there is an 
generation language such as Ada^isn or r sp^ifications mst^d of programs in a 3rd 

the fact that specifications express primarilv ° productivity gain is attributable to 

and detailed i WntattonrTL'S^^X”!^^^^ 

“ general-purpose, we believed an even 
implementations of the extended 

apply transforma^olrules mS^S|e^;:SiSS“™ 

these capabiliries are Ulustrated in the application to commturication systems that we describe 

environment wmJctSo^ forromnmSdon? n?quriemenB analysis and synthesis 

synthesis of different Idn^ of buffers to nvaf t ®"Smeenng. Specifically it addresses the 

operation of the protoS? we discu^^^ requirements. Before Ulustrating the 

impact of the requimnSts’ analyses on S?pKS^^^^ 

synchros and m asJncUoS^s p^ processes, or between a 

We list several general properties that L neS m taowt^Sy 

• the buffer’s input data rate, 

• its functional behavior and 

• the desired type of implementation. 

L'’at^SiS‘oi^ 
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“If process PI transmits data to process P2 and PI is asynchronous ^d P2 is 
synchronous then a buffer is required between processes PI and P2.” 

Similar assertions specify requirements for buffers under other conditions. 

EngineCTS will expect certain parts of the buffer design process to be similar in all cases and other 
parts to depend on the particular context in which the buffer is used. 

The similarities among implementations can be summarized as follows: 

• a data store of some capacity is required; 

• buffer behavior is generally (but not always) that of a FIFO queue; 

• we may assume data can be removed from the buffer at a constant rate, because the output is 

assumed to be synchronous; 

• we may assume that the mean input rate (over suitable intervals) is equal to the output rate; 

• overflow control may be required; 

• underflow control may be required. 

Differences among implementations will include different values of parameters in the above buffer 
attributes (e.g., the actual capacity of the buffer); also, we expect 

• different specifications of functional behavior for different requirements, and 

• different implementations in different environments. 

Input data rate requirements analysis. We first consider three possible characterizations of 
input data rate; 

• approximately Constant, 

• normally distributed and 

• bursty. 

Alternative implementations of the buffer store are appropriate for the different characteristics of 
iriput data rater ^ ^ ^ 

• approximately constant: fixed-length array, length dependent on: 

— input rate distribution, 

— output data rate and 

^ . .9 

— r^uirement on avoiding saturation."^ 

2 A model for determining buffer length is given in Lynch [9] 
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• normal distribution: dynamically-allocated structure such as a list 

* bursty: a combination of array and list. 

Overflow control requirements analysis. Next we consider possible requirements on 
butter beha^or under overflow or near-overflow conditions. Possible choices of overflow 
behavior include: 


• input process blocks. 


• no blocking; oldest data lost, 

• no blocking; most recent data lost, 

• feedback to an input filter control, 


• feedback to an input aperture control, 

• feedback to an input sampling control and 


• adaptively changing the buffer store size. 

appropriate in some situations. For example, in a textbook 

rSmnnH ^ ^ ^ process typically is represented with a guarded 

command that waits (blocks) unul space is available. In a radar system, a buffer receiving plot data 

oldest plot data. In a mouse click handler on a workstation, the buffer may drop 
thm^hfilJS because *e display handler cannot keep up with rapid clicks and^ 

^ be meaningful. In digital transmission of ^alog signals, 

eedback to control the sampler, aperture or filter may be appropriate. 

Underflow requirements analysis. Underflow control is often necessary to insure that there 

f h" cause loss of synchronization and an eventual loss of data. 

I ossible ways of handling underflow mclude: 

• output process blocks 


• output process extracts a “null” data item 

• feedback to an input filter control, etc. 


The discussion thus far should provide an idea of the kind of requirements a communications 
S"SSse resulting design decisions that must be made in building a system to 

Buffer analysis requirements and synthesis in Refine. 


We indicate how knowledge about buffers is represented in our REFINE-based prototype and how 


Buffers are an object class in the knowledge base with attributes that include: 


m 
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apardal specification, common to all buffers and therefore associated with each 
instance of the class 


— input data rate requirement 

— output data rate requirement 


— the partial implementation of the buffer, in its partially refined form 


Figure 1 sh^s some of the attributes of the buffer object class and the possible values of these 
attnbutes. pe order in which the attributes appear reflect approximately the range from highest 
abstraction level (requirements) to lowest (coded implementation). 


Buffer 


Input data 
rate 


Acceptable 
prob. error 


• Approximately constant 

• Uniform distribution 

• Bursty 


• 0 < pc < 1.0 


Undcjrflow i • 
behavior I • 


Output pxkcss blocks 
Extract a null data item 
Feedback to input filter 
etc. 


Store size 


[derived] 


Overflow 

behavior 


Input process blocks 
Oldest data lost 
Newest data lost 
Feedback to input filter 
Feedback to input ^rture 
Feedback to iiq>ut sampling 


Functional 

specification 

Implementatio n 


[partly derived] 
[derived] 


Figure 1: Buffer object class, attributes and 
possible values for attributes 


When the need for ^^cular buffer is recognized by the system, an instance of the buffer obiect 
generated. The values oi the input data rate, oumut data rate, and partial implementation 
attnbutes may at this point m the development be undefeed. They will become defined and may 
change, as the system draws conclusions about the use of the particular buffer. 

Note that in particul^ a taolwedge base object representing a buffer contains the partial 
miplementation of the^ffer as an attribute. It is this feature of our representation, along with the 
retention of previous KB state via the context mechanism, that enables backtracking to previous 
design stages, and reimplementation of the buffer with a different design decisiotir ' 

fes^otot^^”^^^ abstract buffer instance in the application-specific language developed for 

the-buffer BUFFER-1 with-input-data-rate 9600 baud 
discipline FIFO with-uhderfiow— action 
EXTRACT-NULL has-element-data-type CHARACTER 

Some of the attributes of the buffer have been defmed-for example, the input data rate. The value 
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wcause not all the attnbutes of the buffer hav<* specification is abstract 

buff. su.e has no. ye, been defined.^ 

* Other 


^ ^ AHipicincn canon. 

and eno,ypdonS!SSfS S 

' - obJ- in 

synnu nee. These nees axe anno.a,ed a^^il^' ^‘Tatys^prSS' 

bnfSTra^ffis d,S^.Sng‘ ™ “>™nnnicadon system in which this particular 

The-comm-s ystem C*^-! wi4-K 

oonmunicates ALPHANt,M^RIc"data“n^ 

has SPORADIC traffic hToIT 
with nominal rate SOK^if 

Th- . ,., . nnd peak rate 65K baud. 

“^MysnoAing about implementation details except that a 

communication system that do not attributes of the 

=SS=B?“SS€s=SF— 


Transfomutdon rules mpmsen. possible mfinemen« of a bttffer 

ifnct rvf j ^ 


— v/A u uiuicr 
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Other transfortnation rules are more complex and deteimine details of the buffer specification and 
implementation. An example is given in Figure 2. This transformalion rule derives part of the 
buffer’s detailed functional specification (the buffer store). The specification to be derived depends 
on, among other things, the type of the data to be stored and the required overflow action. These 
rules, which are fired after the high-level attributes have been determined, are entirely automatic and 
do not require user intervention. 

Thus the user supplies engineering knowledge and guidance, while the system handles program- 
ming details. In particular, the underlying RHINE system is capable of deriving implementations 
automatically from complete functional specifications, and thus the user concentrates on higher- 
level, application-oriented tasks rather on coding. 


Rule Make-Data-Structure-for-buffer-contents (a: DATA-BUFFER) 

A = '##r comm- grammar 
the-buf fer @n 

with-overf low-action 0o-a 
element-data-type 0d-t 

implement ing-data-structure 0undefined' 
and def ined? (d-t ) 

and impl-ds = new-var (build-syrobol-name ( [n, ’data)), 

(if o-a *= ’ f lush-newest-rec[uire-reset then 
'tuple (integer, seq(0 (copy-expr (dt) ) , 
boolean)’ ebse “ ■ “ ' 

'tuple (integer, seq(0 (copy-expr (dt) )) ' )) 

— > 

variable? (impl-ds) = true 
and initial-value ( impl-ds) == 

(if o-a = ' f lush-newest-require-reset then '<0, [), true>’ else 

'< 0 , []>') 

and scope (impl-ds) » 'global 

and bufer-data-structure (a) - impl-ds 

and lisp— code (impl-ds) = undefined 

and lisp-initializat ion ( impl-ds) = undefined) 

Figure 2: Transforniation rule to constrtKt buffer store 


Note that, in general, if a buffer has n high-level properties and each of these attributes have m , , - 
possible refinements, then representing each refinement as a transformation rule requires roughly 
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would require on the order of subroutines to represent this knowledge 

buffers in the form of transformation^rules repVelJnte 

that needs to be written, and a coirespondingWase in reS^aSi^ decrease in the amount of code 

devdopStX^S SdSrweM * "!T system 

implementations. The paraSgm iTbLed on^Ae detailed ^ifications and 

rules are correctness-preserving. Transformation rules are a ™ k?‘ transforaiation 

representation technimie comnared tn cuKtt^ highly reusable knowledge 

necessaiy to make a refmemeSSp but ttie dSpMm “ 

automatically, the possible choicest nrpcenft.d environment is unable to proceed 

user provides highdevel specifications Ld ra^mmts" Th“s the 

assumes the burden of developing the detail3Z^^!IfAr!!?^ development environment 
allowed to concentrate on the annlication nmhlJm S ®^P®”se the system builder is 

specification, we conclude that^ir annmfoi, k P^^^ y requirements analysis and 
productivity in sXSSdevXSS^^^ increases in 

pmgrammcrs as the 
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t Abstract. 

Thr^obustness® °J 

technology, developers ^?ocutdTn'' 

and'^r o™"d investmenTIn sof.:a^ 

environment'''?ha? frees^'‘thT''en engineering 

possible from fL engineer, to (he extent 

Sesigrand^IvelopS "TZ 

permitted to concenTra^i' software engineer is 

problem resolution qilnn creative aspects of 

maximize portabllilv '^'*3 

svstGmc; hardware and operatina 

and permit thp interfaces which enhance portability 

betm^li^'atie'rvrb: r,t ,"®» h 

and development tprhni aveloped. Software design 

receive increasing em jasis F portability 

portino an aho ^ ®^Pnasis. Experience gained in 

environments fs evaluated" i" h®'' ''^^>''''9 

to maximize s^tt^^tToda'biliJf' 


Introduction. 

(SAVVAsTis":n”auTom^atTiod System 

requirements during develonmpnt • nianage and track software 

Digital Equipment c'orporatr S^ - a 

has been ported to the IBM SAVVAS 

delivered to NASA to suDoort ®°f°^''''^_^®h''ironment and will be 

Station Software Support Environmenr^NASA 'sSET^For'ih 

cLrtler^r^®"arintoS'°"'''^ " i-ma^eri:?^ ^0^0^^ 

relatively simple emSedrd “"alg^o^ZTlr'’ ® 

approximately 25,000 Ada lines of Ze mci OAWAra'®""® 
the services of a databa«;p mon^r. ^ tLOC). SAVVAS depends on 

originally designed to use the (DBMS) and was 

subsequently modified truse the OR Ari p T®' 

VAX/VMS environment, and uses ORAr^F '®,K"°rrf.' *''® 

Figure 1 illustrates the SAVVAS arehttectur^ environment. 

r?***** WG£ BLANK NOT FKJIWD 
' trfeli Jftroi^tn'tlMU! •««* 



Software Portability. 

The degree of software portability is defined as the relative ease 
with which source code can be moved between alternative hardware, 
compilers, operating systems, and other external interfaces. High 
degrees of portability are desirable in order to protect software 
investment, prolong product life, and promote software reuse. As a 
result new technological innovations can be easily introduced. 
Various measures can be taken to improve software portability. 
However such measures may also adversely impact software 
performance in several ways. 

Applications written in Ada have been reputed to be liTg^ 
portable. While the Ada language has been standardized (MIL-STD- 
1815A) and extensive compiler validation tests have been developed 
to evaluate the "degree of standard compliance by Ada compilers, 
high degrees of portability can be difficult to achieve unless 
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features and . ‘'se of certain language 

matures, and standard or virtual interfaces. Each of these Is 

experience" ' * the SAVVAS port and in light of previous 

Isolation of Non-Portable Code. 

from enni’®'!, '® " elit^inate all non-portable code 

«n':“"arS"o, feTd^'T'^ su'^h as^curo^ 

soecial rnntmi ^ display require the transmission of 

operminrsvs em Irrus^ 'h® 

operating systems wT anneT®r ®''®'®®t- Some 

filename^. O h^rs Ti no? '^Th i® 

software ren ho ^ associated with porting 

software to classes o? such 

depend^r control son ^ 'unction declarations with specific machine- 
illu?irate? = , ^ ®® '®°'®'®'' to the package body. Figure 2 

niusvat? ano"hTr'%'^' P®®^®9® a?so 

dependent code to the ^ K aiachine 

the oackan? ® f?®9® a® illustrated in figure 1, only 

linked Mn^nth°'^^ ^® 'acoFipiled before the program is re- 

to a package ' b7dr"?h""''® ®'’“'®‘® °< ®hanges 

development Lsk minimizing recompilation time and 

mav ho ■ _i ^ niany applications only a few such packaaes 

Experiencrhafalso .h"” nonportable sourcP code 

code ca? hi! *"®' "'aatifying all non-portable source 

in bizarre program er'ro?s that aaPatccted occurrances often result 
Clearly lesLni lTar?ed in7h more difficult to correct. 
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package SIMPLE_TERMINALJNTERFACE is 

procedure GO_TO_POSITION (X, Y: in INTEGER): 

procedure DISPLAY_TEXT (MESSAGE: in STRING); 

end SIMPLE_TERMINALJNTERFACE: 

with TEXTJO; use TEXTJO; 

package body SIMPLE_TERMINALJNTERFACE is 

procedure GO_TO_POSITION (X, Y: in INTEGER) is 
begin 

-- Send the appropriate code sequence to the terrninal. 
" These are different for varying terminal types, 
end GO_TO_POSITION; 

procedure DISPLAY_TEXT (MESSAGE: in STRING) is 
begin 

-- Send the message to the terminal 
-- including any required code sequences, 
end DISPLAY_TEXT; 

end SIMPLE_TERMINALJNTERFACE; 

Figure 2. Simple Terminal Interface Package. 


With respect to terminal interface, the mechanisms ava il able on 

the IBM 3090/VM system are radically different from tho'se^ on 
VAX/VMS systems. The block oriented nature of IBM terminals 

required significant changes, and in some cases wholesale rewrite, 
of the human interface modules. This is not surprising in spite of 
the fact that SAVVAS has a very simple menu-driven interface. 
IBM’s Interactive System Productivity Facility (ISPF) was utilized to 
recreate SAVVAS menus. The object modules created for each 
screen were then linked into SAVVAS. Another important design 
feature which minimizes software porting costs is to use software 
layers of increasing abstraction. This simplifies conversion to 
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a'eXivef at, -'^°duc,ion o, 

Of product devXr, abstraction depending on the degree 

Contraints on the Use o, Certain Language Features. 

that some Ada tamuto^r previous experiences demonstrates 

exempt prev^is roorienctL®' T For 

rely on tating and t ir^ h demonstrated that programs which 

much less e htn? (at IvT, constraints may be 

perhaps less otrJiizt burvallfed" °>ber 

Ada comDiler DrnviHoc’ r, compilers. Validation of an 

performance. There can also^b^*^^^*^^^ ''©spect to run time 
of Ada pragmas. Praomacf implementation 

example the Ada oraoma "int r ^ compiler directives. For 

the compiler in the Mnkinn provide direction to 

environment, e. g atemblv otmh 

modules. Many comoilpr*; n^n^ h ° foreign language developed 

single vendors comoiler ?nftul/ ^ unique to only a 

clearly less oortab^ h.n features is 

y less portable than programs which do not. 

data tatpufattottd ttrttmd " 

is dependtt on some DBMA nr !?']' ' SAVVAS 

supplied C-languaoe routinec ^ n^'- leeteres and is linked to vendor 

a stand-aloneToo?for r VAX/VM^^ 

software developmem proiec^ Th„ ™ U.S. Navy 

on a pragma tioue 7 7 nJ^ original impiementation relied 

IMP0RT_VALUED PROCEDURE-^to^im^t called "pragma 

the DEC Ada envTronmpnr c h '^po^t object modules outside of 

most relational DBMSs these^ access ^o^hrf^s 

IMPORT_VALUED PROCPniiRP" • purpose of "pragma 
passing mechanisms for linkan specify parameter types and 

supplied pragma '^his DEC- 

allowed under comoiler valirtaf stated previously, is 

many approach^ to defi^ inp^'?h ''epresents but one of 

required in linking external nfoH P^^^meter passing mechanisms 
the IBM environm^rimp^ -ed in 

say. extensive rework^ was reo^ufrld T to 

sophisticated database intprfa/-c ^ because of the rather 
attributable solelfto th^./t requirements. This extra effort is 
, soieiy to the usp of non-standard language features. 
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This problem was compounded by the fact that the DEC praqma 
permits parameter declaration "out of order." Since such out of 
order parameters in many cases compiled successfully, erroneous 
programs resulted that were very difficult to debug. 

Ada's exception handling is a powerful feature designed to assist in 
the construction of fault tolerant software. Typically the software 
designer identifies potential categories of software failure creating 
specia y named exceptions and providing procedures for software 
recovery in the event of failure. The exception handling feature also 
provides a pre-defined "others" category of exceptions to be used for 
unanticipated exceptional conditions. Deeply nested exception 
hand ers each of which has a catch-all "when others" path make for 
bul et proof programs that won't fail catastrophically. They also 
make programs extremely difficult to debug since it is virtually 
determine at what level the software failed. The 
S experience indicates that the payoff in decreased test and 
debug time usually exceeds the cost of additional care in the design 
of exception handlers. 

Virtual Interfaces. 


The intent of a virtual interface is to isolate application 
so tware from perturbations in the external environment. Virtual 
interfaces have been developed which provide interfaces from Ada 
application programs to relational database management ‘systems, 
human interface systems, graphics display devices, and even 
operating systems. These interfaces are sets of standard calls 
providing basic facilities Tor accessing external capabilities. If 
these interfaces are robust enough, applications are buffered from 
changes in the external environment. For example technology 
advances such as a new database machine may be easily integrated 
into applications without incurring undue software maintenance 
costs. In a sense virtual interfaces are an extension of the idea that 
non-portable code should be isolated. In effect virtual interfaces 
standardize well known classes of non-portable source code. They 

therefore enhance software portability and protect software 
investment. 

Ada/SQL is a proposed virtual interface to relational DBMSs It 
provides standardized native language (Ada) access to relational 
databases using SQL-like syntax. SQL, or ‘^fructured Query Language. 
IS an American National Standards Institute (ANSI) approved 
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other' databas?^access^app^^^ relative merits of Ada/SQL over 
module approach, are still being debLe^d ^It 

mature virtual interface tn roiof^ i 1 ^ however a relatively 
written using Ada/SQL can paqII Applications 

database mLageS system 

especially easy once the "stanri^rw" ^ ^ environments is 

interface have' been developed non-portable components of the 
modules can simply be olunnpH • rnative DBMSs since these 

swapped in. The databaqp^^iQoif^ ° application and a new DBMS 

using the new DBMS but applicatiZ snh ' P°P‘J'a'ed 

IS significant that during the'^ SAVVAS i-emains unchanged. It 

to the Ada/SQL virtual interface Tht changes were required 

this interface is identical nn hel^^ntr''''® ™Ptements 

capability is critical to larae svste systems. This 

many millions of dollars S^uch tepresenting investments of 

into- specific vendor produces br iT' "'°'=kuh 

interface procedures. ^ relying on the vendor supplied 

port to me mM^aogf sTvZfprobr 

area occurred. Some of thpco . the database interface 

to resolve. However all if amounts of effort 

limitations/bugs or unidentified nnn^^ resolved to compiler 
For example, the oriqinal softwa^ro h software modules, 

any user disk space cduW halrw^te^ that 

true for the VAX but not so for the IBM ' 

are obvious to the "mondav mnmm Assumptions such as this 

difficult to detect in practice quarterback" but are sometimes 

environment are often^ quite subUe^Tnd'°can underlying 

software design. ^ can permeate an entire 

System''."°'i%vXTfmm® mseamh"Tt^^^ 

Technology into a network Massachusetts Institute of 

yet an ANSI standtd Tha; hit PV^um. While not 

computer manufacture’s, includtg "oE^'^Dr *’1 "chber of 

was not employed on SAVVAA hfj ^ 

developed and employed ^numerous it ^ ‘’P®" 

The^^AdTra'^di^g t;r;^tma7T^^ 

construction of human interfaces arwo^rbe '"ustd": ptce'ot 
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deveipper created terminal interface packages such as the simple 
example included above. 

Standards for graphic displays are also important. Several have 
been proposed such as the GraphTcs Kernel Standard (GKS). An Ada- 
GKS Binding has been developed to virtualize this interface for Ada 
applications. 

Standard operating system interface^ such as POSIX have also 
gained considerable momentum. Other candidates include the 
Common APSE Interface Set (CAIS) and the European-sponsored 
Portable Common Tools Environrrient (PCTE). Each of these are 
attempts to provide a standard set of operating system primitives. 
POSIX is receiving widespread support in industry, government and 
academia. Ada-POSlX bindings are being developed. Programs such 
as the NASA SSE are evaluating these alternatives in the hope of 
finding a suitable standard. A virtual interface to the operating 
system would eliminate many of the portability problems which 
result from subtle assumptions about the external environment such 
as the user disk space issue discussed above. 

Conclusion, 

Clearly a consistent software design methodology coupled with 
design and coding standards which enforce effective modularization 
and limit the use of less portable language features is essential to 
achieving a high degree of software portability. Standards and 

guidelines should be constantly reviewed and updated based on new 
insights and experiences. 

Virtual interfaces such as Ada/SQL, the X Window System, POSIX 
and Ada-GKS significantly contribute to software portability, and in 
addition have significant productivity implications. These tools 
should be incorporated into Ada software libraries and made readily 
available to the software development staff. On the other hand they 
also clearly add to program performance overhead, and must be 
weighed in light of performance requirements. 

The SAVVAS port has validated past experience and cautions with 
respect to achieving software portability and will be capitalized on 
in future tool development and integration efforts. The SAVVAS 
experience also highlights the importance of adequate training to 
take full advantage of an advanced programming language. Putting 
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result^inTria familiarization courses will not normally 

p'acllces LSTn" engineering 

are error-prone difficuu''tQ^'rleh*^*^'* a written programs that 

. . ' Qi»ncult to dobug, and costly to maintPiin 9 a\/\/ac 

^ W'th''r^Ld ex "erien'ce and 
Trm ^ software engineers which conducted the port to the 

™ h'mSs"' ^hrs'^ prograL'^rs wr e 

adeoua^ .re ■ J reemphasized the importance not only of 

=:s.“£a;S 


83 



— ^ —Qj 
j<^52^5d 

N94-71143 


Gokul Bhaumik 


Modernization of Software Quality Assurance 


PAGE bLANK NOT FILMED 



85 



86 


NEED FOR MODERNIZATION OF QUALITY ASSURANCE 

FUNCTION 


Inoth'^cimiiar ^ programmer-analyst, in a sense, has followed 

a path similar to the Freemason of the middle ages. During the early days of tho 

of how to build a®computerizeJsys,lm 
caiH licensed for personal success. It has been 

deslfln^notymi^ K^-w’ were built much like the Wright Brothers 

«iA«^^finf ^hing. somehow, push it off a diff. and ff ft 

flies, fine. If it crashes, start all over again. Of course some desions wero 

weSl^V°JM and individual tallnt. but - lik^the bu^f 

n«A^ for ?fi ^ K 9nps with all the variables of system design The 

need for results have out-raced the time needed for developing technioues to 

oradurt-f^'rhT’ im^portantly assuring the quality software systems or 

oSfn Comn± W. Luke, Presiderit. Inione 

MinTon “" software, 


NEED FOR QUALITY MANAGEMENT 

The customers satisfaction depends not only on functional oerformance it akn 

“''oracterietics of soflwLe produSs CZs 

wen^Sa^H >’0 0*0'"'"^ »"ioh will pro llde a 2^^ 

well-defined framework for quality assurance functions to improve the iL-wcle 
activities providing significant leverage on software quali^ ^ 

dyey^l? Py ">any quality experts and 

Quality cannot be added on. It means that unlike present day traditional 

engineered from the vfty begSning 
of the software development process. The quality function must s art at 
the same time when system conceptualization begin^ 

duality built into a program is a function of the quality 
‘ during the development process. Standards^ 

are needed to define these attributes °1f 
they do not exist, the quality process remains a subjective evaluS^on 

therefore, must be managed. It must be planned it must be 
organized. It must be directed and it must be regulated or controlled. 

provoking comments, therefore, lead us to the necessarv 
definition of Software Quality Assurance function. necessary 
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Defihition; Software Quality Assurance is a formal, planned approach of actions 
designed to evaluate the degree of identifiable set of quality attributes present 
in all software systems and it^attendant products. 

To support the above definition, the architect of quality evaluation must plan and 
implement necessary tools, techniques, and methodologies in such a manner 
that brings to fruition another important advocacy advanced by many experts in 
the quality disciplines ; 

”A strictly bfche^rated^^ I between the design and 

development processes or product and their concurrent verification 
measures for attributes relative to quality." 


QUALITY MANAGEMENT ROLE 

The Quality Management Role on any Software project must then be to: 

• Monitor 

• Regulate 

• Evaluate 


the Software Development Process and Products and recommend/lnitiate 
necessary corrective action(s) as depicted in the following figure. 
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QUALITY EVALUATION 


Quality Evaluation, necessary criteria must be established for 
both the process and the products as well. . ooiaunsnea lor 


PROCESS EVALUATION CRITERIA 

• Activities required by approved project plans are performed. 

• Processes are compliant with the approved project plans. 

• are utiLed^^'^^^^ ^ Methodologies described in the project plans 

• Processes are adequate to meet the contractual requirements. 

• Adequacy of configuration control system 

" srid corrective action system. 


PRODUCT EVALUATION CRITERIA 

• Compliance with contractual specification requirements 

• Adherence to required format and documentation standards 

• Technical Adequacy 

• Consistency with indicated documents 

• Traceability to indicated docurnents 

• Appropriate degree of Quality attributes(factors), namely, 

Correctness, Efficiency, Flexibility. 

Integrity, Interoperability. Maintainability 
Portability, Reliability, Safety, Reusability. 

Testability, etc 

• Adequacy of test cases.and test procedures 

• Completeness of testing 

• Adequacy of retesting. 
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SR&QA TOOLS AND METRICS 

A significant amount of the work done to evaluate quality is manual, tedious, 
and subject to human error. Tools are desirable in order to monitor 
development process, compliance to standards, change control etc. Automation 
aids should be used extensively to simplify many of these tasks to overcome the 
complexity and volume of products. Automation aids can be used to correlate 
and centralize the software requirements. Software design can be directly 
verified by software tools. A variety of design and code checkers, both static and 
dynamic should be used for detailed verification of resqltant code. Traditional 
review/audit checklists can certainly be made computer aided. Some other tools 
are: 


• Impact analysis tool 

• Requirements traceability matrices 

• Test specification tool 

• Regression test identification tool 

QUANTITATIVE EVALUATION OF SOFTWARE QUALITY UTILIZING 

METRICS 


In order to evaluate quality quantitatively, quality of software must be defined in 
terms of measurable attributes of software and only then mechanism can be 
devised to measure it quantitatively. 

Light and Fisher have defined software quality as "the composite of all related 
attributes which describe the degree of excellence of computer software". 

General Electric study, sponsored by RADC, has refined the above notion of 
quality further into identifiable factors which are some conditions or 
characteristics that contribute to software quality. 

Based upon the result of these studies, T. J. McCabe has defined the process of 
Quality Evaluation as the identification of Important factors in a given 
environment, the specification of these factors and the measurement of the 
degree of their presence during and after implementation. 

Units of metrics are defined as the ratio of actual occurrences or non- 
occurrences to the possible number of occurrences of certain software 
attributes. 

Defining the actual metrics that are used to determine the quality of a specific 

product is beyond the scope of this paper. 


evTluat°on”p¥o^ automate the quality 

Through the Space Station Freedom Software Support Environment(SSE) 
Project, we are called upon to meet a new challenge in orchestrating a quantum 
leap forward in software development productivity and methodologies. 

The ^SE architecture provides an important quality technology breakthrouqh bv 
allowing me implementation of quality evaluation techniques in an automated 

support results from the "product test control" features 
inherent with the SSE framework. The following figure describes the information 
flow in and out of a SSE System Project instance that supports quality 
management. The SSE instance not only ensures the application of quality 
crimna, it also maintains current status data on the progress of development 
and quality evaluation. 
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I 

In summary, the SSE architecture, supporting the automated quality evaluation 
is in the process of bringing to fruition already stated advocacy advanced by the 
quality experts and that is: 

"a strictly orchestrated Interdependency between the design 
and development processes or products and their concurrent 
verification measures for quality." 
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Empircal Studies of Software Design : Implications for 
!, Software Engineering Environments 

Herb Krasner, Lockheed Software Technology Center 

1. INTRODUCTION 

The empirical studies team (Herb Krasner, Raymonde Guindon, Diane 
alz, Neil Iscoe. Vincent Shen, Barbara Smith. Bill Curtis and Nancy 

1986-87 in order to gather data on professionals designing software 
systems in a range of situations. The first study (the Lift Experiment) 
tifp r protocols in a controlled laboratory setting to study 

(the Object Se^er Project) involved the observation, videotaping Ind data 

S “1° development prefect ovef * 

Field dynamics. The third study (the 

Field Study) involved interviews with the personnel from 19 large 

development projects in the MCC shareholders in order to study how the 

organizational and project behavbr 

The focus 0 this report will be on key observations of design process (at 
several levels) and their implications for the des^n of envifonS^ ‘1 

2. OBSERVATIONS 

In our study of individual, experienced designers working on the lift 

ZZl : whtr and ^ Lions 

the ways in which many levels of abstraction and detail are worked at the 
same time, the ways in which designers understand arkf ^aZate 
requirements through explorations of their mental mod^ oJ ^r^Llem 

s=rr“"— 

nsidenng slated or inferred constraints during solution ^ 

ormat'on 5) difficulty in keeping track of and returning to 

f solutions, 6) difficulty in keepLg track 

P™'®"S'°nal designers were 
PAGE £JLAf>iK NOT FILMED ^5 


In our longitudinal design team study [Walz, Elam, 

Krasner and Curtis, 1 987] we observed the processes of group 
disagreement about goals, processes, plans, issues and system design. We 
saw that problems can arise in the 

accomplishment of a group task when individual team members hold 
conflicting assumptions, goals, beliefs, etc, which are not surfaced 
and/or resolved. These conflicts can cause conflicting or incompatible 
system components. Team members attempting to integrate various 
individual efforts may find difficulties/incompatibilities due 
to the differences in these underlying beliefs. The process of design by a 
team is an information pooling task and therefore difficulties in 
communication can be expected. The identification and characterization 
of design "inflection points" can lead to more effective management of the 
divergence/convergence process in team design. Implications for 
software environments to support a high performance design team were 
developed. 

In our field study of 1 9 large software projects, we identified the key 
problem areas spanning the boundaries between project, organization and 
external settings. We identified problems in; the acquisition and 
dissemination of sufficient application knowledge, the effect of 
requirements change and uncertainty, the artificial barriers to software 
technology transfer, the dynamics of design evolution and the special 
problems of government contract developments. We also ideriMied and 
described project level phenominae related to multi-group interaction as 
[Krasner, Curtis and Iscoe, 1987]: 1) the typical communications 
breakdowns in large programming projects, 2) the cultural and 
environmental differences that create barriers to effective intergroup 
communications, and 3) the boundary spanning activities that coordinate 
five crucial topical networks of design information. Four types of 
communication breakdowns observed on the projects were characterized. 
Implications for software environments to support large projects of 
remotely distributed teams were developed. 

3. CONCLUSIONS 


Across these 3 studies we observed how some breakdowns 
occur, how some get solved, some get amplified, and how some 
new types occur as you go from individual toleam t6la^e"p^ro]ects 
and organizations. The mechanisms underlying the breakdowns 
at the individual level were the lack of knowledge about some 
important aspect of the design or limitations in human information 
processing and memory capacity. At the team and orgahizatio'hal 
levels these mechanisms were still important precursors of many 
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byinte,personalTndtgan1zatirr^^^^^^^ 

teams to compensate for individual limitations. These are the 
tone!!, d I ^ abd synthesis cannot be effectively 

™ :: ;s'* 


4. The Lockheed STC Effort 


The Lockheed STC Software Process Management Group is currentiv 

component, he d ‘he SSg 

components, the decomposition of system requirements/desion.s the 

pCrouirr 

P ject resources, the coordination of models of the desion and itc: 
process across project staff, the constraint-based exploration 
of requirments under changing/negotiated conditions andTe 
capture/reuse of historical design rationale. 
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i llllfi; Tool Interoperability in SSE 01 2.0 
Aulbflis: C.L.Carmody and C.T.Shotton 
Dale: October, 1 988 

This paper presents a review of the concept and 

ZoTrtT''°" Space Station Software 

SSE t^a^ o^ ^ 'hP oP'ore of the 

vorkstations andt "'V''’"™"’®"' '"'®™PP^PP"«y ' between SSE 
t ons and hence, between the tools which reside on the 

vorKstations. Specifically, word processor and graphic tool 

nteroperability are discussed. 

™P'P'™'«Pd in 01 2.0 is 
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Tool Interoperability In SSE 01 2.0 


Background 


ne SSE System is an integrated system consisting of computer hardwam 
communication networks ^ cwsro 

management o™7Saco „ c c 

r:='rs::~~ 

L7 ! ' SSFP software, including itseif The 7e 

System will provide a common environment for software support to the SSfp 
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Typically, a Space Station Freedom software development project will consist of 
several developers and testers working as a team. Each team member will do a 
major portion of his work on his own workstation (any one of the supported 
workstation types), and then place that work under configuration control on the 
host for integration with the work of others. In order for that integration 1o take 
place, whether it be the integration of code, of design products, or of document 
sections, there must be a concept and method for the interoperability of 
functionally equivalent tools. 

In OI 2.0, a portion of the functionality that is allocated to the workstations is the 
preparation of document sections, both text and graphics. To satisfy that 
requirement, the workstations are equipped with the following word processing 
and graphics packages; 

• Microsoft Word and MacDraw on the Macintosh II 

• Microsoft Word and Gem Draw Plus on the IBM P/S 2 

• TnTerleaf 3.6 on the ApoTlolfor both text and graphics)™. 

Each word processing and graphic package outputs a different format; even 
Microsoft Word on the Macintosh II outputs a different format from Microsoft 
Word on the IBM P/S 2. In order to support the common text and graphic 
functionality (with distinct output formats), 01 2.0 contains a set of transformation 
procedures which will transform tooPspecific format to a common 
interoperability format, and from that format back to tool-specific format. 
Planning Research Corporation (PRC), subcontractor on the SSE project, has 
developed a set of word-processing transformation procedures, to support a 
Text Interoperability Format (TIF), and a set of graphic transformation 
procedures, to support a Graphic Interoperability Format (GIF). 
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The Concept of Tool Interoperability 


Mac II 


Apollo 


P/S 2 ; 


Project Object Base 


text 

graphics 


developers and 
testers work 
on any of three 
SSE workstation types 


text and graphic objects 
are placed under 
conriguration control 
in interoperability format 


^ the set of transformation procedures 
and the defined interoperability formats 

^ ^ the flow of text objects 

the flow of graphic objects 

_Figure 1, T he Concept of interoperability within SSE OI 2. 0 
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figure are spelling correctly, and the figure itself conforms to project graphic 
standards. Using the transformation procedures, the tester does not need to 
have the same type of workstation as the developer; he doesn't even need to 
know on what kind of workstation the objects were originally developed. And, if 
an object needs rework, a different developer with a different type of workstation 
can do the rework. Ultimately, when all planned tests are passed, the objects 
are integrated into the final product on the host; in this case, a document. [SSE 
OI 2.0 also contains transformation procedures which will transform text and 
graphic objects from interoperability format into a merged document using the 
VAX host-based document processing tool, Scribe]. 

As shown in Figure 2, Text interoperability Procedures, there are six text 
transformation procedures; three transform tool-specific output into text 
interoperability format, three transform from text interoperability format into a 
form acceptable by the SSE baselined wordprocessors. 


Microsoft Word on IBM 
(DCA format) 




Microsoft Word Text 

on Macintosh (rtfin"^ — ^ Interoperability 

(RTF format) ^ Format 


Interleaf on Apollo 


LEAFIfif) 


Microsoft Word on IBM 



(DCA format) 

(INTDO^ 

Microsoft Word 


► on Macintosh 

ClNTLEAF^ 

(RTF format) 


interleaf on Apollo 


Figure 2; Text Interoperability Procedures 


As shown in Figure 3, Graphic Interoperability Procedures, there are six graphic 
transformation procedures; three transform tool-specific output into graphic 
interoperability format, three transform from graphic interoperability format into a 
form acceptable by the SSE baselined graphic packages. 
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f^igure 3; Graphic Interoperability Procedures 
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I, Data Type Transparency: "the SSE will shield the user from explicit, 

’ required knowledge of the data types addressed for work in levels where 
such is not appropriate" 

Integration; "the SSE will be a tightly integrated whole, centered around 
a policy of software life-cycle management. Tight integration is comprised 
of maximizing information transfer between SSE functional capabilities 
with a simultaneous minimization of user intervention." 

Use of Ada; "the SSE supports the use of Ada for the development of all 
SSP operational software, including itself 

Vendor Independence: "the SSE design will be highly portable so as to 
avoid dependence on any particular vendor, computer hardware system, 
workstation, data base management system, operating system, network, 
or application program. The interoperability features provided by the 
SSE System remove much of the dependency on vendor-specific 
hardware and software, minimizing the risk in that area" 

Transformation Procedures Design Drivers 

Maintainability: Once a vendor puts out a word-processing or graphic 
package, there is no guarantee that when an update is released, the 
vendor will have maintained the old format. The lack of control over 
vendor outf)ut has forced the design of the transformation procedures 
into a highly data-driven design, to reduce impact on the software when 
the Input file format changes. 

Reusability: Each transformation procedure is structured in a similar 
manner, using the same skeleton Ada package specifications, and 
calling the same service procedures. When a new transformation 
procedure is required, it is not developed from scratch, but rather 
assembled from existing components and tailored for its new use. 

Portability; The SSE requirement to support equivalent functionality on 
each host architecture has driven the transformation procedures to 
identify and isolate machine dependencies. 
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Reliability and Usability; The transformation procedures are used several 
times daily by nearly all current SSE developers and testers; the PRC 
developers have made reliability and usability the highest of design 
priorities, the PRC testers have exercised creativity in the design of test 
cases which attempt every unforeseen way of making the software fail. 


Implementation Details 

Each transformation procedure is either a LALR(1) parser or a context sensitive, 
recursive descent parser, which scans the input format and, based on parse 
tables containing the syntax for the input format and action rules transforming 
input constructs into output constructs, creates a file in the desired output format. 
(An LALR(1) parser Looks Ahead from Left to Right 1 symbol) Rather than 
writing each parser from scratch, a public domain parser generator (developed 
for NASA Langley) was used to create the skeleton for each transformation 
procedure and the parse tables to be used by the transformation. The parser 
generator used was PARGEN, part of the MYSTRO suite of compiler-compiler 
tools. PARGEN takes as Its input a production grammar which describes the 
transformations from one format to another In unambiguous terms. From this 
grammar, the LALR(1) parse tables are built, along with procedures to do the 
lexical analysis, or scanning, and the syntax-semantics synthesis. 

t 

As SSE is required to be completely in Ada, PARGEN was modified to generate 
Ada, and all host-resident transformation procedures are written in Ada. Due to 
vendor restrictions on access to their proprietary formats and routines accessing 
thesp. formats, two transformation procedures, GEMINT was developed on the 
IBM P/S 2, and PICTINT was developed on the Madntosh II; both in C. 

Interoperability Formats 

Key to the design and implementation of the transformation procedures Is the 
definition of the interoperability formats. Each format (text and graphics) 
attempts to define in a fool-independent format that funcflonali^ wf^joh is both 
common to all baselined workstation tools and required by the majority of the 
users. Both text and graphic interoperability are defined in Backus-Naur Form 
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(BNF), however the graphics interoperability format provides a, more extensive 
object-oriented language, by virtue of the nature of graphics, and standard 
manipulations on graphic objects. For example, drawing a rectangle filled with 
your choice of patterns is a fairly standard capability for a graphics package. 

Significant Challenges 

Any integrated system (office automation, software development, etc) which 
provides a set of tools with equivalent functionality should provide some means 
for the interoperability of those tools and their outputs. It is worthwhile to review 
some of the challenges that must be taken into consideration. 

Parsing techniques; the development of the SSE transformation 
procedures required an in-depth understanding of parsing techniques, at 
least equivalent to the information provided in a typical compiler design 
course. Properly managed, the entire team need not have this degree of 
expertise in compiler construction, but should have mastery of the 
fundamentals of the theories involved. 

Determination of common functionality: Probably one of the most 
controversial aspects to achieving interoperability is the definition of the 
interoperability format. During this exercise, the common subset of the 
functionality provided by the baselined tools is defined formally as a 
grammar. The main problem is dealing with users who would prefer the 
interoperability format to provide a superset of all the functionality 
provided by the tools. 

Control of vendors; The SSE Program has no control over the schedule 
of update releases from vendors, or the content of update releases. This 
can create serious schedule problems, as the transformation developers 
attempt to keep up with several package updates at once, especially as 
an older package may cease to be available before the corresponding 
transformation procedure or format has been updated for the updated 
package. A second severe problem is the access to the vendor formats. 
Not ail vendors subscribe to 'open systems'; as a result some 
transformation procedures must reside on the sy stem on which the 
vendors provide access routines to their proprietary formats. The ideal 
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solution to the problem of controlling vendors is to publish the 
interoperability formats, for use by each vendor to provide their own 
transformation procedures. 


Plans for 01 3.0 


Transformation Procedure Maintenance 

No extensive enhancements in the word processing and graphic transformation 
procedures are planned for SSE 01 3.0. Typical maintenance will consist of 
making any changes necessitated by vendor updates, modify any undesirable 
features, and analyze the widening of the interoperability formats. 


Design Tool Interoperability 

A sigraficant enhancement to SSE tool interoperability is planned for 01 3.0 
roug the introduction of a new class of transformation procedures. PRC plans 
to define an interoperability format and implement the transformation 
procedures to bring about interoperability between the SSE baselined CASE 
tools, Cadre's TEAMWORK on the Apollo, Excelerator on the IBM P/S 2. and 
conix PowerTools on the Macintosh. Again, the most significant challenge will 
0 determine the common required functionality and a means for 
representing that functionality in a production grammar. The transformation 
P ocedures themselves will be built upon the legacy of the word processing and 
graphic transformation procaduras. 
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UNISYS" experience IN SOFTWARE 
QUALITY AND PRODUCTIVITY MANAGEMENT 
:: OF AN EXISTING SYSTEM 


By John B. Munson 

Vice President and General Manager 
Unisys Houston Operations 


A summary of Quality Improvement techniques, implementation 

results in the maintenance, management and modification 

of large software systems for the Space Shuttle Program's 
ground-based systems . 
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UNISYS' EXPERIENCE IN SOFTWARE QUALITY AND PRODUCTIVITY 
MANAGEMENT 

For more than a quarter-century, the Johnson Space 
Center (JSC) in Houston, Texas developed and operated large 
computer systems to support manned spaceflight. Until three 
years ago, JSC used 11 contractors to develop, operate and 
maintain these systems. Integration and management were 
performed by government personnel. 

In 1985, JSC decided to separate system development 
from maintenance and operations. Unisys Houston Operations, 
as part of the Rockwell STSOC team, was selected to manage, 
modify and maintain the Space Shuttle Program's ground- 
based, flight-support sy st e ms 

We are responsible for the Shuttle program's more 
than 14 million lines of executable code, which was written 
in 15 different programming languages. The code operates on 
equipment made by eight manufacturers, and runs on 173 
computers located in 13 separate JSC facilities. 

The software spans the entire life cycle of every 
mission, including flight planning, astronaut and flight 
controller training, flight simulation, flight software 
verification and flight support. Our Shuttle program 
software responsibilities encompass JSC's: 

o Flight and Mission Planning, 

o Flight Software Verification 

o Flight Simulation and Training, and 

o Mission Control Center Operations and 
Communications . 

In addition, we support the integration and testing 
of all associated software and its flight-to-flight 
reconfiguration. Our software includes the code that: 

o monitors the Shuttle's launch, orbit and 
landing; 

O maintains communications between JSC and 
other NASA centers and flight support facilities, as well as 
with the Shuttle itself; 

o tracks the Orbiter's progress, performance 
and physical state; and 

o calculates the amounts of oxygen, water, 
fuel, electricity and other critical onboard resources for 
every flight. 

We must complete our work accurately the first time 
and every time in order to attain the quality essential to 
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Shuttle operations, and to meet cost and 

error of a magnitude sufficient 
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strive for 100% employee participation in all .aspects of the 
Quality Improvement Process. 


How we achieve quality 

The emphasis on quality must flow from and to 
management. Employees have deep motivations to fulfill 
management expectations. When management emphasizes 
quality improvement and provides the direction, resources 
and goals to attain it, management commitment is visibly 
demonstrated. It is essential that employees understand the 
sincerity of our efforts. I personally participate in the 
initial sessions and graduations of our Quality Education 
classes. 

Through this Quality Education for all employees, we 
provide a hands-on training environment which assures that a 
consistent set of quality principles and concepts will 
develop an organizational mindset for quality improvement. 
An infrastructure of Quality Improvement Teams, Steering 
Committees, and Corrective Actipn Teams raises the level of 
quality awareness and the effectiveness of the quality 
improvement process. We also document all software 
processes, standards and procedures we employ; measure 
process-defect yields and their rates of occurrence; and 
conduct formal, corrective action reviews. 

We have instituted the Oregon Objectives Matrix as 
an aid to record and report our measurements of quality and 
productivity factors. The Oregon Objectives Matrix, 
developed by the University of Oregon, is used extensively 
in the Unisys Defense Systems Group, of which we are a 
division. The matrix provides a graphic method to track and 
report several measurements on just one page. This enables 
managements to quickly see trends in the measurements, which 
are tracked monthly. 

Quality improvement is an integral part of 
everything we do. There are two very important aspects of 
our Quality Improvement Process - the Quality Engineering 
Process and the Quality Assurance Process. These are two 
distinctly different processes performed independently of 
each other . 

It is the responsibility of the engineering 

departments to define, document and implement processes 
assuring that we produce quality products . It is the 
responsibility of the Quality Assurance Department to read, 
understand and supervise implementation of the defined 
processes. We have the capability to file nonconformance 
reports against the engineering process when product defects 
are discovered, and within the engineering departments when 
the correct processes are not followed. 

In our software work, the engineering process begins 
with the detection of nonconformances. We initiate a 
thorough investigation to determine why the defect occurred, 
then we correct it as soon as possible. In addition, we 
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How we achieve high reliability 
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o incorporate redundancy whenever possible, 
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O establish failure/recovery procedures. 
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Reisults to date 

Our efforts in quality and reliability improvement 
have y ielded outstanding results, particularly in terms of 
productivity. Some of our major accomplishments are listed 
below. 


o Reduced our independent verification and testing 
schedule by six days, saving 440 labor-hours for 
each major software release 

o Reduced the number of database trajectory 

discrepancies attributable to database reconfig- 
uration from 80% to 5%. 


o Reduced the mean-time to close discrepancies from 
40 days to 2 days 

o Achieved a 10% reduction in the backlog of change 
requests 

o Achieved a 40% reduction in the backlog of 
discrepancy reports 

o Reduced our mean-time to evalute new changes 
from 16 days to 9 days 


Future plans 

We will continue our Quality Improvement Process for 
the length of our Space program software responsibilities. 
We will continue to evaluate every software process that is 
instituted.. In addition, we will: 

o improve the quality characteristics of all 
supported software bases, 

o establish a requirements engineering program and a 
test engineering program, 

o consolidate and standardize wherever possible, 

o refine and evolve our metrics for measurement 
processes, and 

o automate software support and operations whenever 
possible. 

The Quality Improvement Process we employ was adopted 
virtually in toto from the renowned Crosby method. The 
process is now used throughout our entire corporation, but 
we at Unisys Houston Operations are proud we were one of 
the first divisions to implement the process and are a 
leader in its application. 
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Next Generation 


“ Howard Yudkin 
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The synthesis prcx:ess for incorporating reuse and prototyping ideas into large software system 
development suggest how the acquisition process might be changed to support the new development 
process. 
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SOFTWARE ENGINEERING 
AS AN ENGINEERING DISCIPLINE 


A Panel Presentation for 
RICIS Symposium '88 


OJ 


Chaired by 

Dr. Glenn B. Freedman, Director 
Software Engineering Professional Education Center 
University of Houston - Clear Lake 
November 10, 1988 




Purpose of the Panel 


To explore the emerging field of software 
engineering from a variety of perspectives: 


4 University Programs 
/ IndustryTralning and Definition 
/ Government Development 
V Technology Transfer 
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NTRODUCTION 


The pane] will address the issues of what a 
current definition of software engineering 

might be and what that definition could 
become. 


The panel will address the issues the 
distinctions among software engineering, 
computer science, and computer hardware 
engineering as they relate to the challenges 
of large, complex systems. 




INTRODUCTION 



Software life cycle Issues are 
Increasingly Important for all 
organizations. 

Software systems that are large, 
complex, distributed, non-stop and 
have Indefinite life spans must be 
engineered for change — education 
and training systems must also be 
responsive to the environment. 

There are two kinds of software 

engineering costs; for acquisition and 
for ownership. We can pay now or we 
can pay later. 


Higher productivity can result from 
use of modern software engineering 
practices, software reuse, use of 
commercial products, education and 
training, automated support, and 
good management. 
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Meeting the Challenge of Industrial Software Development: 

the Boston University 

Graduate Program in Software Systems Engineering 


Panel Presentation 

"Software Engineering as an Engineering Discipline" 
NASA/Johnson Space Center and RICIS Symposium 

U) 


Joh W. Brackett, Professor 

Department of Electrical, Computer and Systems Engineering 

Boston University 



Key Aspects of the Boston University 
Software Engineering Program 


• Integral part of the College of Engineering 

• Embedded system orientation 

- required courses on hardware 

- Ada as principal language 

• Developed to meet industrial needs in cooperation with 
Corporate Advisory Board 

- ATT Bell Laboratories 

- Digital Equipment Corporation 

- GTE Laboratories 

- Hewlett Packard 

- MITRE i 

- Raytheon 
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Software Engineering Skills 
Lacking in Most CS Graduates 

• Hardware/software integration 

• Requirements analysis 

• Test planning 

5 • Configuration management 

• Design experience 

• Project planning and scheduling 



Goals of the Boston University 
MS in Software Systems Engineering 

To provide graduates with 

• theoretical foundations needed to assess and 
new hardware and software advances 

• understanding of, and experience with, tools and 
methods for embedded system software development 

• managerial skills to plan, organize and lead 
a software development project 

• experience as a team member 
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4 Strategic Decisions 


• To build a wide base of industrial support in order to 
ensure long-term financial viability 

- Corporate Associates Program 

- Corporate Advisory Board 

• To use interactive television to reach part-time students 

• To emphasize software which is integral to 
a hardware product 

• To develop the program in the College of Engineering and to 
seek faculty support for it as an engineering discipline 



Why Software Engineering 
in the College of Engineering? 


• WHY NOT?? 

- relationship to systems engineering and computer 
engineering due to embedded system emphasis 

- little Interest in an industrially-oriented program In 
BU Computer Science department 

- existing faculty have science and engineering degrees 

• Eliminates problems with an "engineering" ddgree 
that is not in the College of Enginering 

• Engineering is the natural home for Software Engineering 
in the long term 

- computer science is to software engineering as: 

chemistry is to chemical engineering 
physics is to electrical engineering 
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Current Program Status 

; I- 1 : -f . 

• Enroliment as of 10/88: 

- 5 full-time students - 

- 20 part-time degree candidates 

- 50 special students 

• 4 faculty teaching required courses 

• 4 courses a semester on interactive TV 

• Over $1 .3 million in support raised in 1 8 months from 

- Digital Equipment Corporation 

- Hewlett-Packard 

- MITRE 

- Raytheon 



Embedded Systems Laboratory 

• State-of-the-art showcase supporting modern software 
engineering techniques for building embedded systems 

• Network with 20 VAXStations and target machine equipment 

• VAX Ada environment and "industrial grade" support tools 

5 • Central compute and file servers with remote access 

• Over 50 mips of computing power 

• Graphically-oriented analysis and design tools including 
Teamwork and Statemate 

• Made possible by grants from Digital Equipment Corporation, 
Cadre Technologies and i-Logix 
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Prerequisite Structure 
Hardware Background 
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Prerequisite Structure 
Software Background 


SC503 

Switching Theory j 
& Logic Design 



sc 

Applica 
Formal I 

517 1 

itions of 1 
\4ethods 1 
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SC511 
Software 
Systems Design 
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Fall Semester 


Spring Semester 



Software T rack 
Sample Full-Time 
Program 


SC912 

Software 

Engineering 

Project 


Summer 











Implications of Remote Delivery 
by Satellite Television 


• Will only be available to corporate sponsors of the 
educational program and selected government agencies 

- 8-1 0 major corporations 

- 2-3 agencies supporting Ph.D. research 

tmmJk 

On 

• 7 out of 9 courses can be taken on interactive television 

• Courses with team projects (51 1 and 518) require corporate 
support for 2 faculty visits and easy access to software 

One semester required on campus for the degree 

- "Computer as a System Component" requires the 
Embedded Systems Laboratory and close faculty supervision 

- "Software Engineering Project" is done in 4-6 person 
teams with frequent faculty interaction 
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Objectives for the 
Next 3 Years 

• Grow enrollment to steady-state of 60 FTE students 

- 25 full-time on campus 

- 70 part-time Boston area (on campus and local TV) 

- 70 part-time outside Boston area (satellite TV) 

• Develop additional laboratories 

§ - human-interface laboratory 

- networking/distributed processing laboratory 

• Build software engineering faculty to 6 

• Develop Ph.D. program and software engineering research 

• Be recognized as the leading graduate program concentrating 
on software engineering for embedded/real-time systems 
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Software Engineering 
as ah 

Engineering Discipiine 

Edward V, Berard 
EVB Software Engineering, Inc. 

5320 Spectrum Drive 
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Software Engineering as an 
Engineering Discipiine 
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Raeaarah Inatht^a for 
Qorrpi^g and lr>rorrr«tleKi 

Oystami 

Unfvtrtily ol hfouiton, 
OtowUiko 
NovfrrUf ID, IBBS 


Edward V. Berard 
EVB Software Engineering, inc. 
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EWfirtIng •oftwjtht Cn0lnf«rlnff 


What Is Software 
Engineering? 


O Early Use of the Term 


O 1968 NATO Conference 


O Barry Boehm’s Definition 


□ Four Requirements for Software Engineering 
O Additional Criteria for Software Engineering 
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Oeflnfng Mtwam Eftplneerin^ 


Eariy Use of the Term 


□ "Coder" - Early 1950s 

□ "Programmer” - Mid 1950s 

O "Programmer/Analyst” - 1960s 
P "Software Engineer”- 1980s (1963) 
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□ Is 




^ NATO Conference on 
Software Engineering 


different from 


°fnta7l T"' engineering 


»EV8 In,., 


0»Hnlng»ot,»„ enBln.,,1^ 


Barry Boehm’s 1976 
Definition of Software 
Engineering 


v»wiwairo engineering is the «nn].v,. • 
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CHMnini Svftmiv EnglnMHnB 


IEi^0iRi&9ir3i^§ I 

Four Major Requirements 
for Software Engineering 



1. Computer Science 

2. Mathematics 

3. Engineering Disciplines 

4. Excellent Communication Skills 


(o«7,ioaa 
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Defining EnglnMHitg 


Computer Science 


Programming Topics: Algorithms, Programming Languages, 
Programming Style, Debugging and Verification, 

Applications 


n Software Organization: Computer Structure and 

Organization, Data Representation, Symbolic Coding and 
Assembly Systems, Addressing Techniques, Macros, Program 
Segmentation and Linkage, Linkers and Loaders, Systems and 
Utility Programs 


□ Hardware Organization: Computer Systems Organization, 
Logic Design , Data Representation and Transfer, Digital 
Arithmetic, Digital Storage and Accessing, Control and I/O, 
Reliability 


□ Data Structures and File Processing: Data Structures, 
Sorting and Searching, Trees, File Terminology, Sequential 
Access, Random Access, File I/O 



«CV» Enftneadni, Wm,. 1H7, 
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Otfining ChglnMMng 


Mathematics 


a 

n 

D 

O 

o 

□ 


Integral Celcuiua 
Special Functions 
Differentia] £<|UBtions 
Linear Algebra 
Diacrete Mathematics 
Set Theory 
^ Graph Theory 
□ Numerical Analysis 
O Complex Analysis 
n Probability 
O Statistics 
n and mnrn 
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OaUnlng toMwafv CnglriMrlng 


Englneafing Disciplines 

O Error Analysis 


O Metrics 
O Methodologies 

Configuration Management 
Quality Assurance 
Testing 

✓ Debugging 

✓ Maintenance 

✓ Development 

O Project Management 


: ^ 
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Otftning Cn^ln««rln9 


Additional Skills Needed by 
Software Engineers 


n Creativity 

□ Ingenuity 

□ Interpersonal Communications 
O Analytical Thinking 

n Logical Thinking 

□ Organization 

□ ... and more 
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Software Engineerinq 
Training 

Given that software engineering is at least 
as mvolved, as technical, and af raptdlv 
evolving as more formally recogniLd forms 
of engineering (e.g., electronics ' 

appropriate to 

speak of the need for software engineering 
education , than for the need for software 
^gmeering traming 



ftoftw^rp enfltfv^rrnfl Tralnlna 


A Healthy Dose of Reality 

• ■ 


It is given that: 

y' Software engineering education at the 
university level is virtually non-eiste„t 

The need for properly educated 
software engineers is enormous 

There are literally hundreds of 
theS^* “programmers” already in 


♦SV» 
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CnglnHrtna Training 


Observations 




□ “Sciemific” programmers are far less likely to accept software 
engineering as a discipline than are "business” programmers. 

□ “Scientific” programmers arc better etjulpped to handle the 
mathematics and technical rigor associated with software 
engineering than arc their "business” counterparts. 

□ Europeans more readily accept the rigorously technical nature 
of software engineering than do Americans. 

n The Japanese will do whatever is required, but seem to prefer 
rote methods as opposed to thinking. 


O The Japanese arc far more willing to invest in the long tenn 
than arc their American or European counterparts. 



Siro^Sira^irQijti^ |_ 


gpfWvpr* fngrriMrffiQ Trslnlng 


Observations (continued) 




□ Software engineering in the United States often involves the 
installation and automation of technologies which are at least 
ten (10) years out of date. 

□ The “half life” of software engineering technology seems to be 
about three to four (3-4) years. 

□ Computer Aided Software Engineering (CASE) is a very 
frequently used term, but its actual implementation, in most 
cases, involves little more than an automated graphic design 
toot. 


□ People other than programmers, e.g., managers, are often 
ignored by CASE. 

□ Many lifc-cycle activities are ignored by most CASE 
environments, e.g., activities outside of development arc often 
ignored. 


I HI 
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i.ylliik. 


0bSGrV3tl0nS (continued) 

° “Vlronmems not only umomnic 

^ limv™7 j?® “vlronments are one-dimensional (e g 

O Too few environments arc seamless (e.g., Rutional™). 

^ ^ >"ifg«'ating CASE tools with in-house 

devclS^em rnethodologies. and 

out-of-da,e before those 


•EVa In^., 1 «| 7 . 1»H 


^^3wa}ips 


enaioMrina Tt«inifl 0 


[ Observations (conunued) 

mSr.?' w: P™8y«mraers (There are very few 

O New technology is seldom what we expect it to be 

° S;r 

° SSs““""?r “ 


•tVH BofMtt* 1^6., IM7. tail 
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Robert B, MacDonald 

(NOTES) 
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Software Engineering as an 
Engineering Discipline 


Norman Gibbs 
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Education Program 


Software Engineering Institute 

Carnegie Mellon University 
Pittsburgh, PA 15213 


oponsorea oy tne U.S. Department 




Cam^glt M«lor> Unlvwslty 

^ftware Engineering Institute 


Chailenge 

The SEI shall develop and conduct courses and 
seminars with respect to the evolving state of the 
art and practice in software engineering for 
mission-critical computer systems as well as the 
results of its activities in technology transition, it 
shall influence software engineering curricula 
development throughout the education 
community . " 

-SEI Charter 


*1^ BLMAK not FtMED 

Wov lOEDnegl 


163 



Cam«gle MeKon University 

Software Engineering Inslitute 


Education Program Goals 

• Increase the number of highly qualified software 
engineers 

- new software engineers 

- existing practitioners 

• Be the leading center of expertise for software 
engineering education and training 


Nov 10EDri9g2 



Carnegie M^on UnJversIfy 

Software Engineering Institute 


Education Program Objectives 

• Accelerate the development of software 
engineering programs in academia to increase the 
quality and quantity of the next generation of 
software engineers 

• Enhance continuing education opportunities to 
improve the quality of the current generation of 
software engineers 


Nov 10EDneg3 
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CinwgJe Melon UrWersily 

Software Engineering Inslitule 


Problem Definition 

Substantial advances In the practice of software 
engineering require a solid educational foundation 

Rapid developments in software engineerina vs 
enormous Inertia of the educational system 

Need more new software engineers 
engiYieers^^^^'^^ productivity of current software 

Need more qualified educators 

Need more and improved educational materials 

Need to identify the fundamental principles of an 
emerging discipline 

Must balance principles and current best practice 


Nov IQEDnegA 


Carnegie Mellon University 

^gineering InsUtufe 

Strategy 

• Identify, organize, and document \Y\e body of 
knowledge of software engineering 

* TOrtmafS'""'® educational 

• Design, develop, and keep current a model 
curriculum for a graduate degree 

* use of advanced technology for deliverv 
of software engineering education anatraining ^ 


Nov lOEDnagS 


165 



Cam«g{« M«lon Unh/arsity 

Software Engineering Institute 



Carnegie Melon Urriverstt/ 

Software Engineering Institute 


Graduate Curriculum Project 

Purpose: 

• Promote graduate-level software engineering 
education 

Major goals: 

• Identify, organize, and document the body of 
knowledge that might be taught in graduate-level 
software engineering programs 

• Design, develop, and support a curriculum for a 
Master of Software Engineering (MSE) degree 


Nov iOEDnog? 
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Carnegie Meffon Unh^ersity 

Software Enqineerina Institute 


Graduate Curriculum Project 

• Module development 

• Support material development 

• MSE curriculum 

• Ada artifact 

• Addison-Wesley book series 


Nov lOBDnegB 


Carnegie Melon Unh^arai^ 

Institute 


Undergraduate Software Engineering 
Education Project 

Purpose: 

• Influence existing computer science 

flnH pi'ograms to increase the aualitv 

and quantity of software engineering contlm 


IM 
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Camagl* Melon Unh^erstty 

Software Engineering InstUute 


Undergraduate Software Engineering 
Education Project 

Providing support materials for teaching the senior 
level software engineering project course 

Identifying the needs of educators and students 
for more software engineering content 

Examining the use of Ada In the undergraduate 
curriculum and Ada as a first programming 
language 


Nov lOEDneglO 


Carnegie Melon UrWersity 

Software Engmeerfng Institute 


Advanced Learning Technologies 

Project 

Purpose: 

• Demonstrate the applicability to software 
engineering of technologically advanced learning 
media, such as 

- interactive video discs 

- intelligent tutors 

- advice-giving expert systems 

- compact disc read-only memory 

- digital video interactive equipment 


Nov lOBDnogll 
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Carnegie Melon UnNersfly 

Software Engine ering Institute 


Advanced Learning Technologies 

Project 

• First prototype developed to demonstrate 
feasibility 

• Producing a course for demonstrating the 
applicability of digital video interactive and 
compact disc read-only memory technologies 
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Camegfa Mellon University 

Software Engineering Institute 


Video Dissemination Project 

Purpose: 

• Produce and deliver courses on modern software 
engineering methods to practitioners in 
cooperation with the academic, government and 
industrial communities. 


Nov 10EDnog13 
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Cam^^a Mellon University 

Software Engineering tnstitute 


Video Dissemination Project 

Studio completed 

Pilot Course offered at CMU in January 1988 
Academic Series 

- Formal Methods in Software Engineering 

- Software Project Management 
Continuing Education Series 
Current Technology Series 
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Camagle MeRon University 

Software Engineering Institute 


Faculty Development Workshops 

Purpose: To transition SEI educational materials to 
educators 

• Fall 1986 Pittsburgh -- 110 attendees 

• Spring 1987 -- Pittsburgh — 140 attendees 

• Fall 1987 -- Pittsburgh -- 100 attendees 

• Spring 1988 -- Fairfax, Virginia - 156 attendees 

• Winter 1988 -- Scottsdale, Arizona, January 6,7 

• Summer 1989 -- Pittsburgh, week of July 17 


Ncv lOEDnegIS 
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Carnegie Mellon University 

Softw are Engineennq Institute 


Annual Software Engineering 
Education Conference 


Purpose: Promote an exchanoe of ideas and 
methods among educators from academic 

industrial education and training 
communities ^ 


• Spring 1987 - first SEI conference, 200 attendees 

• Spring 1988 - second conference, first remote 152 
attendees 

• Summer 1989 - Pittsburgh, week of July 17 
Springer-Verlag contract for proceedings 
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Camoglo M«0on Umversfty 

SoUwat^ Engineering Institute 


Academic Affiliates Function 

* ® mechanism for interactions between 
the SEI and the academic community 

• Administered by the Education Program for the 


Nov WEDnegU 
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Camegfe Mellon Unh/ersity 

Software Engineering Institute 


Academic Affiliates 

Accomplishments: 

• 41 academic institutions are academic affiliates 

• 25 scientists have worked at the SEI under the 
visiting scientist program 

• First MSE primary test site has been designated 


Nov lOEDneg 18 


Carnegie Mellon UnK/erstty 

Software Engineering Institute 


Affiliate Activity - 1 

• Module Development 

- Arizona State (3), Boston University, California 
at Irvine, George Mason, Lehigh, Maryland, 
Pittsburgh (3), Seattle (2), Stirling, Wichita State 
(2), William and Mary, USC 

• Support Material Development 

- Arizona State, Pittsburgh, Stirling, Wayne State, 
Wichita State (2) 

• Video Pilot 

- California State at Sacramento, East Tennessee 
State, George Mason, North Carolina, Wichita 
State 
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Ca/negl® Melon Unfvec shy 

Software En gineering Institute 


Affiliate Activity - 2 

• Other SEI Programs 

California at Sacramento, Columbia, Michigan 

• Curriculum Design Workshop 

- Arizona State, George Mason, SUNY at 

Rochester Institute of Technology, 
Wichita State, William and Mary 

• Primary Test Site for MSE 

- Wichita State 


• Ada in Freshman Courses 

Virginia Maryland, Washington, West 
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Carnegie Melon University 

institute 


Current Academic Affiliates 


Air Force Institute of Technology 
Arizona State University 
Boston University 

California State University, Sacramento 

Ctemson University 

Columbia University 

East Tennessee State University 

George Mason University 

Lehigh University 

Naval Postgraduate School 

Old Dominion University 

Purdue University 

Queen’s University at Kingston 

Queen’s University, Belfast 

Rochester Institute of technology 

of Informallcs, Polytechnic University of 

Seattle University 

Slate University of New York at Binghamton 

Temple University 

Texas A&M University 

United States Air Force Academy 


University of California, Irvine 

University of Houston, Clear Lake 

UnIversHy of Illinois at Urbana-Champaign 

University of Maryland 

University of Michigan 

University of North Carolina, Chapel Hill 

University of Pittsburgh 

University of Texas, Austin 

University of Southern California 

The University of Sliding 

The University of Strathclyde 

University of Tennessee, Knoxville 

UnIversHy of Washington 

Virginia Polytechnic institute and Slate 
UnIversHy 

Wayne State University 
The University of West Florida 
West Virginia University 
The Wichita State University 
The College of William and Mary 
Wright State University 
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Cam«9^« Mdicn University 

Software Engineering Institute 


Uniqueness 

International focus for software engineering 
education 

Permanent staff in support of curricula effort 

Catalyst for new ideas 

Notion of an evolving curriculum 

Visiting scientists 

CMU connection 

A research infrastructure exists; we provide 
educational infrastructure 

A center for expertise unlike that in any discipline 
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Camagla Melion University 

Software Engineering Institute 


CMU MSE 


Two year program 
First year remote 

- six core courses 

- Software Systems Engineering 

- Specificiatlon of Software Systems 

- Principles and Applications of Software 
Design 

- Software Generation and Maintenance 
» Software Verification and Vaiidation 

- Software Project Management 

- two electives 
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Melon University 

Software Engineerin g Institute 


CMU MSE 

• Second year in residence 

- admissions procedure 

■ project in three phases - planning, execution, 
evaluation 

- visits by leading software engineers plus 
student tasks to study their work 

" advanced courses 

- advanced electives in software engineerinq 
related topics 


Nav 10EDneg24 
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Computer-Aided Software 
Engineering Environments 
for Real-Time Systems 


Panel Chair and Moderator: Charles W. McKay 

Panel 

Migual A. Carrio, Jr. 

E. Douglas Jensen 
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A Conceptual Model for Evolving 
Run Time Support of Mission and 
Safety Critical Components in Large, 
Complex, Distributed Systems 


Charles W. McKay 
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A Conceptual Model for 
Evolving Run Tine Support of 
Mission and Safety Critical 
Components in Large, Complex, 
Distributed Systems 


Charles W, McKay 
SERC/HTLeUHCL 






INTRODUCTION 

naximite^Ufe^TycYe'suppIrt^f^^^ *’® evolved to 

safety critical^ component? Thfs mission and 

and a recommended approach for tailoring issues 

run time support environmeni-«: ^ conceptual model of Ada 

an application pOIreTisltl con^!? specific needs of such 

described previously b^this authO?^fe 1°^ 

summarized in Figures 1 through 9 . McKay, 1987) and are 

previously pulfllshed^modS^ of^^'d?^ extensions to a 

ARtemg (Ada^ Run Time Environment- environments from the 

first model waO us?0 to ISl? Adf'r?n ‘ 

dependencies, issues features tune: requirements, 

applications; the Darticnia»- nxx^ options for single processor 
not explicitly described distributed processing were 

to address the needed svs'tems this extended model is 

programs in distributed computing enJiroraMS. »PPli=ation 


OVERVIEW OF related CONCEPTS AND TERMS 


"Overview” 

mupportrSjtWogra^ by artewg, this model 

to support not only the this model is intended 

prograi across ? distribuS? entities of a single Ada 

support the distribution of ent?r?^^”^ environment but also to 
across such an environment The multiple Ada programs 

the original ARTEWG model address a extensions to 

multiprocessors, local area nettorL ^ 

area networks of inteorated ^ networks, wide 

of distributed competing System? 

and tailorability of the mnd^i Furthermore the extensibility 
support of such%eratronal reciirV^^^^ facilitate th^ 

fault tolerance, multilevel sec^ity, aL other?”“^^°^ operation, 

have"’VTle^ted®?n^tT^^^^ mapoed^‘^?o^''^^^‘'^^^°" Program which is to 
computing system, -e Vun^Tm^enirror^^^^^^^^ 

BLANK NOT F«.MEC 
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macroscopicaTIy divided into four sets. From the top-down view of 
an Ada application program, the ordered sets are identified as: 
Distributed Information Services (DIS) , Distributed Communication 
Services (DCS) , Distributed Configuration Control Services (DCCS) , 
and Distributed Operating Systems (DOS) . Not all applications 
will need all four sets of se^ices. Even those that do need all 
four are likely to benefit from tailoring to meet application 
specific needs. Consistent with the philosophy underlying 
previous ARTEWG work, such tailorability will be facilitated by 
appropriate subsections of the Catalog of Interface Features and 
Options for each set of services. 

Figure 10 depicts a logical view of these services at a site 
in a distributed computing system. Applications software 
components and users share the perspective labeled Distributed 
Applications Services (DAS) of the DIS, DCS, and the DCCS. Not 
explicitly shown is the DOS which provides integrated support for 
all of the other sets. 

Before proceeding with an introduction to the four interface 
sets, it will be helpful to clarify and distinguish four terms: 
services, resources, architecture of computing systems, and bare 
machine philosophy. Services refer to operations performed on 
behalf of a user. Resources refer to items available to or from 
an object or user where the resources are distinct from the 
services that provide, consume, or affect them. For example, in 
the Ada statement _ "PUSH (x) , PUSH refers to the service and X 
refers ^6 T:Tie resource. 

For purposes of this model, the architecture of computing 
systems refers to: 

The structural organization and the interrelationships of 
the software, hardware, and operational interface elements 
that comprise the system. 

Also for purposes of this model, a bare machine philosophy 
recommends that all source code for: applications software, 
subsystems software, and systems software be written in Ada and 
transformed into executable object code by the same compiler and 
associated tools. This may exclude some small percentage of code 
required to interface machine dependent idiosyncracles to the 
kernel of the system software. The reader should note that the 
bare machine philosophy is in sharp contrast to the approach of 
retrofitting Ada application software to systems and subsystems 
software written in other languages and often representing older 
models and paradigms which are inconsistent with the more modern 
software engineering principles embodied in Ada. 

"Distributed Operating System" 

The DOS encapsulates the system hardware. Three major 
criteria for a good operating system, including DOS's, are: 


182 


1. 













2 . 


operrtiin^"or*^alY managing the integrated 

risourcet categories of system services and 

annl sharable among independent 

application program components and users. aepenaent 

An explicit set of management modules (software 
p^icTer^"''""' interfaces, to implemint “rd”e'nf'’or?rth4 


ruflr'^rnd’’°‘!fnfd°^ operating system which provides 

extension 4“o^nsr\n/7eco^??g“^^^^^^^^ 

cate^rie's o7lyI?“"se«7c°e^"\nl°^SOur'2?s 


1 . 

2 . 

3 . 

4 . 

5 . 

6 . 

7 . 

8 . 


9 . 

10 . 


Workload, jobs, processes, tasks, and processors 
Memory: primary. .secondary 

Devices and buses 
Data and information 

stable Interface Sets: Users and applications software 

systems 


softwarf»^"h^^^^*^^ Sets; Major subsystems and 
software, hardware, and operational interfaces 


Communications: systems. .applications 

Configuration control; 

. ' System services and resources .. applications 

software and users pp-t-j-cations 

• Normal processing. .exception processing 
Time and events 

Access control including security and integrity 
distributed Information Seryicejs” 

a virtua^^nfl^?^c^se*^\no™^ a?\hT Dl1“® p ai 

manipulation of elements of HiJ? example, access and 


"Distributed Communications Services" 


Communications resources 


and services which are to be shared 
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aroong multiple application programs or users in a distributed on- 
line envij^nment should be accessible to the application at a 

view the DIS as a user and vice versa. For example a user 
request from the DAS to the local DIS for a resource of dka mloht 

obtain the local DCS^o 

Obtain the data resource from a remote site. 

"Distributed Configuration Control 
Services" 

V- Figure l, the DCCS virtual interface set has 

provides a unique 

opportunity to exploit known semantics about the various 
components that provide the services and resources of the three in 
order to monitor, manipulate, and control distributed processing, 
r example, programs can be distributed dynamically, processes 

blocked, parameterized performance monitoring 
can be enabled or disabled, and interactive debugging and 
reconfiguration can be supported among remote sites. The reader 
should note that this is a much higher semantic level of 
configuration control services than is typically found in 
underlying operating systems. 

MODEL OF THE EXECUTION ENVIRONMENT OF A DISTRIBUTED 
COMPUTING SYSTEM ARCHITECTURE 


"Abstractions: Four Functional Layers 

and Major Interface Sets" 


i-ho ■'^he major internee sets extend from 
the DIS through the DCS, DCCS, and DOS functional layers down to 

These virtual interface sets built from a common 
Sa ^aioq of Interfacg features and Potions provide a perspective of 
a Portable Common Execution Environment (PCEE) to the application 
program components and users. 


"Issues Common to Each Layer" 


Eight major issues common to all layers and maj 
system services and resources are: 


or categories of 


1. Five Management Responsibilities 

a. Track the Status and Utilization of Each Service and 
Resource 

b. Enforce Policies 

c. Schedule 

d. Dispatch 

e. Reclaim (e.g. Completion, Unrecoverable Fault 

Abortion, Preemption) ' 

2. Measurement, Testing, Debugging 

3. Abstractions: Objects, Messages, Semantic Models 
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4. Synchronization 

5. Protection 

6. Errors and Faults 

7. Naming and Identification 

8. Baseline Modification 


"Issues with a Large 
Potential Return-on-Investment 
PP^i^ization Across Xiayers" 

return-on-invest»ant for 

1. Reusability 

2 . Interoperability and Transportability 

3. System Measurements, Testing, and Debugging 

SsoSrces^‘'^^^°" Reconfiguration of Services and 

5. Universal Scheduling 

6. Universal state Consistency and Congruity 

^ "Important Issues for 

Supporting Mission and 
Safety Critical Components" 

given bill;. ® components of one proposed model are 

Issues and Components of the 
Clear Lake Model for Run Time 
Support of Mission and Safety 
Critical Components: 

developed 4 sustained in Ada upon bare 


Software structuring which facilitates: firewalli 


ing, 


185 


3. 


layered recovery/capability, dynamic reconfiguration and 
extensibility 

Pools of processes and processors capable of non-stop 
operation in a fault-tolerant environment 

4 . A command language interface between the SIS of the 
integration environment's PCEE and the SIS of the target 
environment's PCEE 

5. System-wide, lifecycle-unique identification of all objects 
and transactions/subtransactions 

6. Dynamic, multilevel security in the integration & target 
environments 

7. A message interface which supports three forms of 

communication among clusters: asynchronous send/receive 

with 'no waits', remote procedure call, Ada rendezvous 

8. Hierarchical runtime structure of the threads-of-control 

9. A redundancy management subsystem for services and 
resources which life and property depend upon 

10. A stable storage subsystem for each cluster 

11. A management subsystem for distributed, nested transactions 

12. A multiversion, fault-tolerant programming capability with 
a granularity within any program which extends at least to 
the subtransaction level and explicitly identifies the 
recovery capabilities at that level 

f 


FIRST LEVEL MAPPING TO AN IMPLEMENTATION MODEL 

Figure 12 depicts an extension of the original ARTEWG model to 
include support for distributing entities of Ada application 
programs across components of a distributed computing system. 
Scenarios are useful for explaining the model. Suppose an^ Ada 
application programmer logs into an APSE (Ada Programming Support 
Environment) to prepare a source code version of a program to be 
deployed and operated in a distributed target environment. The 
capabilities assigned to the programmer on this project determine 
whether the DIS, DCS, DCCS, or DOS virtual interface sets are to 
be available to this programmer, (Note that these features and 
options are part of the extended runtime library — ie, XRTL — 
which are documented in the CIFO and legally go beyond the minimum 
set ^ of components in the runtime library which are required for 
validation — ie, RTL.) Along with imports from the explicitly 
"with'ed" applications library, every shareable service and 
resource available at the four interface sets of the XRTL may be 
explicitly referenced within the application source code of the 
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instance of the CIFO.) Now\hr^^Jurce 

inventory of the references to th^ compiled and an 

determine the Ada components which^wn^i^ partially 

system level repositories to ho ^ selected from these two 

as the application code anf compiler 

However, t£o addi?ionS inputs ?rf®toH°. "‘^^^ine. 

remainder of the obiect oo^io determine the 

environment. First the ♦- exported to the target 

determine if i?ln-funotio„^„ checked’lo 

transparent to the aoDlloat-Son requirements which should be 
program. For exSple? the «« t° *PPly to thiS 

•; ; B3 class, multilevel secSr^et^^irl^eLi* 1" 

transparent-to-the-source-code non-functional 

additional components from the^XRTL 

deployment. Finally the transformed for 

«tay cause a sm^ll %rSnt of hardware itsel? 

export to the target environment. code to be required for 

additional work needed to further develop the models 

undertaking whiclf can benef it^”f large and complex 

from issue! on any one of thl fun.tT principally 

;ost crucial issuL are beUeveT^^^^^ the 

Safety Critical components in support of Mission and 

systems. An integrated approach to hh embedded computing 

component support as the first nr^F!^^?^ ®®ts with MASC 

prototyped. first priority should be developed and 
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A NEW TECHNOLOGY PERSPECTIVE & ENGINEERING TOOLS APPROACH 
FOR LARGE, COMPLEX & DISTRIBUTED MISSION AND SAFETY CRITICAL SYSTEMS 

COMPONENTS 


ABSTRACT 

Rapidly emerging technology and methodologies have out-paced the 
systems development processes' ability to use them effectively, if at 
all. At the same time the tools used to build systems are becoming 
obsolescent themselves as a consequence of the same technology lag 
that plagues systems development. The net result is that systems 
development activities have not been able to take advantage of 
available technology and have become equally dependent on aging and 
ineffective computer-aided engineering tools. Nev methods and tools 
approaches are essential if the demands of non-stop and Mission and 
Safety Critical (MASC) components are to be met. 


INTRODUCTION 

Expectedly, the systems development management and technical 
communities continue to remain slow and reluctant to accept change and 
new approaches in spite of the overwhelming evidence in support of a 
need for it, and the disappointing track, record in systems development 
of the last 30 years. The resistance to change in the midst of nev 
approaches and innovative concepts, is accompanied by a perceived 
threat and expectation that there is now added risk to the ever 
escalating cost of development by introducing nev methods and tools. 
The risk and added cost of development, unfortunately, result in not 
accepting and implementing many of the recent approaches and methods 
available in the marketplace and continuing to ignore them. 


ISSUES 


Because of the following, it is strongly felt that new 
approaches to modeling; tools design and conceptualization in the 
initial life cycle phases (i.e., requirements analysis, allocation, 
and design synthesis) are necessary. 

I. Systems have become so large that the traditional concept of 
prototyping is not looked favorably upon due to the large costs, 
expenditure of time, and complex issues raised in developing 
prototypes. 

II. It is a given and well known fact that the earlier in the life 
cycle design weaknesses and errors are identified, the more cost 
effective the design fix and less labor intensive. 
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APPROACH 


The ten points identified have served as requirements drivers in 
molding Teledyne Brown Engineering's TAGS^ technology aimed at solving 
problems early in a cost effective manner. The approach has been to: 

A. Focus on the initial phases of the life cycle to ferret out 
design issues and capture requirements. 

B. Adopt a systems engineering perspective that looks at the 
entire picture (i.e., views hardware and software engineering 
together and as driven by systems engineering). 

C. View alternative life cycle models relative to the specific 
development activity, using automation based paradigms, 

D. Employ a heterogeneous systems methodology with integrated 
conf igurat ion management elements . 

E. Use a systems design language supported by a formal syntax. 

F. Use/develop tools that support and embody items A through E, 


These issues will be addressed, but as a consequence of their 
interrelationships, they cannot be viewed independently. Thus, for 
example, focusing on the early life cycle phases requires an 
understanding of the relationships of the various life cycle phases and 
activities inclusive of the maintenance and operational phases (later 
phases). Furthermore, the iterative life cycle forms and types must 
also be understood. Despite an awareness and extensive documentation of 
the lower costs of detecting and correcting errors in the early life 
cycle phases, program managers continue to Ignore the early phases and 
resources required to support them. The question should be repeatedly 
asked of developers and tool builders - *’Vhy haven't past and on-going 
efforts focused on the early phases to discipline and stabilize 
requirements and design issues?” ”Why haven't the tool builders 
addressed the front or early life cycle phases, and provided the 
marketplace with extensive tools in this area?” The number of 
commercially available requirements generation and analysis tools that 
exist or can be integrated with systems engineering design synthesis 
tools are virtually non-existent, A basic tenet of the automation based 
paradigms is that early life cycle emphasis supported by automated tools 
is a must, if significant achievements in productivity and 
maintainability are to be made. 

The development processes and thus modeling and prototyping 
efforts must be initially viewed and driven from a systems engineering 
perspective. The systems engineering view will insure that premature 
allocations of requirements to either hardware or software are deferred 
until the proper time and more important into the proper allocated 
design specification. A systems engineering view ensures that from the 
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Additionally, if an executable prototype and formal design 
repre!sentation is to be generated and analyzed, then the concept of the 
need for an integrated heterogeneous methodology must be further 
extended to capture and represent other process, logic and algorithmic 
elements down to formal mathematical representations. Thus, what 
emerges is a need to capture both the methodology and design elements 
via a unified and extensive systems engineering vehicle capable of 
representing the engineering processes in a formal representation. A 
sample representation of this is a systems design language, of Backus 
Naur Form, called the Input-Output Requirements Language (lORL).y It 
is a high order language comprised of a character set and a graphical 
set of pictures that support both the systems engineering processes as 
well as the methodology requirements to bring together the elements 
needed for viable design synthesis. 


AVAILABLE TECHNOLOGY /NDI 


TAGS technology consists of three components - a methodology and 
paradigm; a formal systems design language; and an environmental suite, 
consisting at this time of nineteen integrated tools (figure 1). The 
workstation hosted environment is intended to support design teams in a 
networked mode consisting of host, integration and target components. 
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simulation t'o' distributed design and 

target environment characteristicl'^^and^ and independently , emulating 

simulation compiler supported by merge librarru^^^^^^^^^^ a'’"'" 

the Analysis Library enable^- mi-aii i 7 utilities contained iii 

insight into the lar^ef ln,H . ^^tecution modes that provide 

simulation architecture enables rhe"'^" ormance. It's two-pass 

host activities on lesser canaci tv ^ the development 

simulation exportation tn T. workstations, while enabling 

problems requiring such (e e strTr" execution of complex 

e^LCT; ParallfJ^iLraUonrtan^’^t'Te^'forml^^ 


^environmen t components 


TAGS consists of the following tools: 


requirements verification tool set (RVTS) - to assist in 
the management of requirements. The four tools comprising 
this module enable requirements traceability within and 
across specifications, establish parent-child rluuLhip 

thr^sta^hr requirements, alloS 

ablishment of function, subfunction and keyword 
associations, provide a document trouble report capaMHtI 

uitiple i rGm0n 1 5 : r^fprcncG*? intn 4 ^ 

statements, an. provide the' atTu ty o3rcalTge““;: 

different reports and trace matrices consistent with ”Je 
evolving specification tree hierarchies. 

ulaJl! ! storage, retrieval, modification, viewing aL 

feature!! Th^srind '"^au-driven highly interactive 

1 Thg SR modulG providGs sccgss to tHo tori ^ 

Jagfs“%ru ^hel "> P-te^t ?he tsZ 

pages. bR IS thG basic design module. ^ 

A configuration management module (CM) - provides < 5 vct^m 

complexity and network/team size. system 

the'IoRr'I^ analyzer (DA) - to provide static analyses of 
the lORL design pages generated via the SR module ThI 
esign IS analyzed in a background mode, monitored' via 
separate process so as to alloy a continnhion „f X other 
designer activities on a non-interference basis. Designed as 
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an incremental compiler, DA allows the completion of 
individual pages or modules that can be integrated and 
analyzed in a background mode with other completed design. 
Error messages with unique reference numbers provide for a 
rapid and efficient troubleshooting mode that can be 
supported by lesser experienced members of the design team. 
DA performs static analysis (i.e., completeness, consistency 
and closure checks on the design). 

o A simulation compiler (SC) - produces an executable discrete 
event simulation of a system designed in lORL. Tlie 

simulation performs dynamic error analyses which can locate 
problems such as timing and control faults; and errors tliat 
cannot be found through static testing. Also, the resulting 
execution trace listing assists the user in determining the 
optimum system and processing algorithm designs as well as 
performance analysis. 

o An analysis library (AL) - consists of ten tools that fall 
into three categories: 

Auditing - to allow the user instant visibility into the 
design database, and also provides for system partitioning 
and ready identification of all system components. 

Documentation Manage ment - to allow the automatic generation 
of data dictionaries, and provide a document processor 
interface (e.g., POSTSCRIPT). The document processor 
interface provides the user the ability to merge system 
design text and graphics with other commercial document 
processors (e.g., Context^ and Interleaf^) to further extend 
the ability to generate automatic documentation and support 
such standards as Mil- Std-2167 . 

Reusability - to allow the reuse of design, architecture, 
functionality, specifications and code. These tools greatly 
support the reusability development paradigms and enable tlie 
invocation of reusability concepts very early in the life 
cycle. 

o An automatic code generator (ACG) - allowing the designer to 
generate executable source code from the lORL formal design 
representation for transition and insertion into the target 
environment. The code generator thus provides the capability 
to support "software first" development, rap prototype 
paradigms and the early identification , of source code that 
requires further optimization via a lower level software 
engineering environment. Currently, the only language the 
code generator supports is Mil-Std-1815A (Ada), with a VHSIC 
Hardware Description Language (VHDL) , IEEE Std 1076-1987 code 
generator under development. 
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Q»^II^jYg_RESU LTS USING THE TECHNO r.OnY 

nualit;.HL''lnJ^^‘^ technology on two DoD programs has provided both 
qualitative and quantitative results that are most encouraging and 
support predictions of achievable and significantly higher productivity. 

a direc?iotf7hii°''"-^"'^- environment have clearly established 

, . r . . lepiesents: a significant higher productivity yield 

eye es with significantly reduced implementation time scales lower 
development costs (figure 2) and higher design confidence and quality 

roimmini f (Battle Management /Command Control 

Sas hrourl r'"’ ‘he requirements 

phas thiough to integration, test and delivery of software end product 

” hn 1 investment and learning the new 

technology are also factored in. While the total source lines of code 
for each of the systems numbered in the 200-300K range, similar yields 
E would' ,-%--P-cted for larger systems o^’the type SDI or 

the fact thTt'°nrn^^ rationale for this is derived from 

tlie fact that piopam module size for manageability and optimization 

OrsT^han'''*ior\ocr several thousand lines of code 

AH-, should be noted that these two DoD efforts did not utilize the 

Ada Code Generator, since FORTRAN was identified by the user as the 
imp emeiuat ion language. The simulation compiler and RVTS were not in 
pioduc form when these efforts were initiated some fifteen months ago. 

, t 1 C expectation of using the extended tool set in future efforts 
P.OV. os an -on firmer basis for supporting higher produ'uvi ty' 

^ - 1 ^ I ‘h® existence of a code generator and simulation 

compiler enables the developer to begin testing and lntegratiorear?ier 

sofrw supporting higher confidence levels. The delivered 

snecl^i^d il Th satisfactorily as intended a^ as 
specified in the user/operational environment. 
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PROJECT A (N-siTe) 
SOFTWARE DEVELOPMENT 



SOURCE 

METRIC 

INDUSTRY 

STANDARD' 

PROJECT 

EXPERIENCE 

COMPARISON 

(%) 

Lines of Code/Hour 

0.77 LOOhr’ 

2.26 LOC/hr< 

294 

Calendar Schedule 

8.4 monthsL2 

5.5 months 

65.5 

Effort (man-months) 

132 mmi 

45 mm 

34 

Cost per LOC 

$45 to 503 

$14.57 

30.7 

Total Cost 

1M 

S0.237M 

23.7 


1. Based on Boehm: Software Engineering Economics 

2. Compressed Schedule: Normal Schedule ■ 11.6 months 

3. Based on $90K - 1 0OK/man-year at 2,000 hr/yr 

4. Converted 3,1 K LOC of Project B Monitor and Control: Reused Portions 
of Project B lORL* Design 


PROJECT B (SIE) 

SOFTWARE DEVELOPMENT COMPARISONS 
AT BUILD 3 



SOURCE 

METRIC 

INDUSTRY 

STANDARD' 

PROJECT 

EXPERIENCE 

COMPARISON 

(%) 

Lines of Code/Hour 

0.69 LOOhr’ 

1.17LOC/hr 

170 

Calendar Schedule 

12 months'c? 

9 months 

75 

Effort (man-month() 

316 mmi 

188 mm 

59 

Cost per LOC 

$45 to 503 

$34 

72 

Total Cost 

$2.1M 

$1.02M 

49 


1. Based on Boehm: Software Engineering Economics 

2. Compressed Schedule; Normal Schedule « 15 months 

3. Based on $90K - 1 0OK/man-year at 2,000 hr/yr 


Actual Results obtained are shown in the 
"Project Experience" column* The significant 
drop in cost per lines of code (LOC) in 
Project A resulted from the reuse of design 
and algorithms from Project B. 


Figure 2 
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CONCLUSIONS 


dovPlnnil/^^ • "f*" • resulting data from other on-going 

development projects as expected to provide further credibility for use 

paridaVm^’’*'wUh \h^ Invoking the approach and 

einl • u environment identified will almost certainly 

acroinli h"n design confidence and integrity 

accomplishable in significantly lesser times. Early results in Linl 

the technology on other on-going efforts continue to support existing 

tflL ^ .recognized that the technology and approaches will 

themselves continue to evolve to more mature forms. It is a so 

^s^r^ur in'th"^'^ enhancements w U 

as a result of " either as a direct consequence of it or 

with it F ft, ” egiating and interfacing other commercial products 

Wiich exists in ongoing developments today. And, if expectations 

a developer Ms 

and nolSi^ "rJose?" ® available 


REFERENCES 


1 / 

19-/.5. 


Balzer, Cheathem, Green 
Subject: Software 


Paradigm. 


- Computer 
Technology 


, Vol. 16, No. 11, 
in the 1990's: 


Nov. 83, 
Using a 


pp. 

New 


lif. - ^oceedings of COMPSA C 84 Conference on Commitei 

Sottva^^ ^, plications ; Nov. 84, Chicago, m.; IBEE^JOnO^STflif: 
5. Subject: Evolution as a New Basis for Reusability. 

Inc. ~ SofJtware_En£i Peeri ng Economics ; 1981, Prentice-Hall, 


— ^ _ Carrio, Miguel - Proceedings of 

Majrechnol^; March 1986,~A?IiT^iT^ 
Technology Life Cycle and Ada. 


the 4th National Conference 


VA, pp. 75-81. Subject: 


on 


The 


5/ Davis, Alan M. 
88, pp. 1098-1115. 


- Communicati ons of the ACM, 
Subject: 


„ .,. . A Comparison ol 

Specification of External System Behavior. 


Vol. 31, No. 
Techniques 


9, Sep. 
for the 


6/ Jones, 
Software and 
No. 83-640060 
& Issues. 


Proceedings of COMPSAC 8 4 Conference 
Applications; Nov. 84, Chicago, 111., Library 
, pp. 476-478. Subject: Software Reusability: 


on Computer 
of Congress 
Approaches 


1/ Sievert, 
85, pp. 56-65. 
TAGS. 


G. & Mizell, T. - lEEE-Computer ; Vol. 18, No. 4, Apr. 
u ject. Specification-Based Software Engineering with 


8 / 

Vol 


Yadav, Bravoco, Chatfield, Rajkumar 
31, No. 9, Sep. 88, pp. 1090-1097. 


commun ications 


A 'i "A”"' PP- iUyU-109/. Subject: Comnari^^^iT 

na ysis echniques for Information Requirement Determination. 


1 < 


of 


tags is a 
Context i 
Interleaf 


registered trademark of Teledyne Brown Engineering 
s a registered trademark of the Context Corporation 
IS a registered trademark of Interleaf Corporation 


212 



N94- 71152 


Alpha: 

A Real-Time Decentralized Operating System 
for Mission-Oriented System Integration and Operation 


E. Douglas Jensen 


Concurrent Computer Corporation 


Westford, MA 
508 - 692-6200 

edj@cs.cmu.edu, uunet.uu.net!masscomp!jensen 




Alpha: 

A Real-Time Decentralized Operating System 
for Mission-Oriented System Integration and Operation 


E. Douglas Jensen 
Corp^ 

Westlbrd,MA 

508 - 692^200 

cdj@cs.cmu.edu, uunct.uu.nci!masscomp!jcnscn 


Abstract ^ ^ ^ 

system, which is unique in two highly significant ways. First, it is dcccn- 
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Sr^olu.: S"^^U2^1icUon written by General Dynamics Cotp. Continuing r«^h b 
Computer Corp. is leading to a senes of enhanced follow-ons to Alpha- these are noriable hni inf 
ually hosted on Concurrent’s MASSCOMP line of multiprocessor products. S 
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ically or cvcnjogically centralized resource management entity or service, such as a “location broker.” 
‘‘Real-Time” is Different in the System Integration and Operation Context 

Tlic term “real-time” is usually intended to mean "dctenninisiic behavior” and “faster is better”, particular 
ly in die area of interrupt handling and context swaps. Real-time conu-ol in this sense applies only to com- 
puter systems which simply do low-level scnsor/aclualor .sampled-data loop applications, and :irc traditional- 
ly designed to have rigidly periodic behavior. But real-time system integration and operation is far more diffi 
cult because it cncompa.sscs not just such static periodicity but also predominantly dynamic and aperiodic 
activities which nonetheless have critical lime constraints, such as deadlines. Thc.se consU'ainis arc part of tlic 
correctness criteria of the computation, and failure to meet them is a threat to die systerns’s mission and to 
survival of property and human life. Alpha personnel invented a novel approach whereby the application's 
time constraints arc expressed in terms of the value to the system of completing each activity as a function of 
its completion time (deadlines arc a simple special ease— a step function). In addition, actividcs have relative 
importances which arc also time-dependent. These time value functions and importances arc dynamic and must 
lie continuously re-evaluated. Every evaluation is performed for all executing and pending activities collec- 
tively so as to maximize the total value to the system across the whole lime period represented by the expect 
cd durations of all dicsc activities. This sophisticated and explicit treatment of real time has been conclusive- 
ly shown in both theory and practice to be exceedingly cost-effective. The conventional and seemingly .sim- 
pler notions of "priority” in real-time systems are zero’th order approximations which extensive experience 
has consistently demonstrated introduces massive and uncontrollable complexity into all but the most trivial 
real-time systems. Alpha employs this new real-time management technique to rc-s^ve all contention for 
resources such as processor cycles, communication access, secondary storage, and synchronizers (c.g., 
semaphores, locks). Time constraints and importance arc among the attributes propagated with computations 
which cross node boundaries so that resource management can be global. The ubiquitous client/server morlcl is 
unsuitable in this res|xx:l since it docs not maintain such essential correspondences between the service and 
client on whose behalf that service is being provided. 

Alpha exhibits a fundamental philosophy which is contrary to that of OSs for other application environ- 
ments. Instead of optimizing performance of the normal cases at the expense of infrequent ones, it does the 
opposite. It is in the exception cases such as emergencies (c.g., being in danger due to attack or failure) when 
a real-time OS must be depended upon to perform best, even if the system’s routine behavior must be compro 
mised to ensure that. This is one of the principal reasons why real-time UNlXs are inherently limited. 

Of course. Alpha also has all the features usually sought in real-time operating systems, including a fully pre- 
cmptable kernel, synchronization, asynchronous notification, i/o directly to/fiom user space, conuguous files 
on disk, memory-locked objects, pre-allocatable resource pools, low interrupt latency and seryices limes, etc. 

Extraordinary “Adaptability” is Essential to Real-Time System Integration and Operation 

Real-time system integration and operation applications arc very complex, and arc not (perhaps cannot lx:) 
well understood; in addition, the environment and technology are always in a state of flux. Tlius, the func- 
tional and performance requirements for their computers evolve continuously throughout the entire life cycle 
of the system, which can be decades. Alpha accommodates this situation through a variety of techniques, many 
of which arc quite innovative. Its design is kcmelizcd and strictly adheres to the principle of ixilr- 
cy/mcchanism separation. Specific OS policies arc carefully excluded from its kernel level mechanisms so that 
a wide range of different service facilities, and indeed entire DOSs, can be effectively constniclcd using 
Alpha’s kernel, in accordance with application needs. For example. Alpha’s kernel provides atomicity, scrial- 
izability, and permanence as orthogonal mechanisms. Conventional atomic transaction facilities bundle all 
three properties together, witli correspondingly high overhead, as the only choice of policy regardless of need 
and affordability. But the client layers of Alpha’s kernel can base tlicir policies on other combinations of 
these mechanisms. For example, there arc many instances in real-time systems when problem-specific consis- 
tency consuainis yield correct results more efficiently tiuui scrializabiliiy would, or when pcnnancncc is not 
worth its cost. This same jiliilosophy is followed in schctluling, communications, and all other lyixts of 
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resource marvigcmcriL ” " * 

Computers embedded in real-time systems usually must produce the higlicsl |x)ssib]e pcrfonnance from the 
allowable liardwarc size* weight, and power, including memory space fbfllic OS. A general-purpose ccun [fill- 
er system can easily be an order of magnitude lower performance ilian a spccial-punx)se one for a paiiiailar 
application. Thus, to achieve llic balance of performance and flexibility needed for cost-effect ivencss in a imil- 
lijdicity of changing system integration and operation applications. Alpha is general -purpose but unusually 
malleable so as to exploit all the problem -specific static and dynamic infonnaiion available from the applica- 
tion. In addition, application functionality can readily be migrated downward into the OS. and even into its 
kernel, for incrcitscxl performance when necessary. 

Alpha’s internals arc organized so dial its subsystems such as scheduling, communications, secondary storage, 
etc. can all execute truly concurrently at each node. We intend that these separate hardware points of control 
wiUiin Alpha arc a mixture of dynamically assigned general-purpose processors (i.c., each node in the decen- 
tralized computer can be a multiprocessor) and algorithmically specialized liardwarc accelerators (co-proccs- 
.sors and other forms of augmentation). Alpha extends to its client applications die same opportunities for 
taking advantage of multiple special-purpose as well as general-purpose processors at each node. 

Alpha presents a programming model which is object oriented, in the sense of abstract data types. This impos- 
es a structure and discipline conducive to modular software at both the DOS and application levels, as well ;is 
improving fault isolation. The active entity, or unit of logical compulation, is a thread sU'inging througli 
objects via operation invocation, without regard for address spaces or node bounckirics; fundamental disuibu- 
lion and reliability issues arc the responsibility of Alpha instead of die user. Tliis network uniformity and 
iranspiircncy greatly aids the creation and modification of distributed applications. 

Status 

Alpha Rclca.se 1 (done at CMU) has been demonstrated to DoD agencies since late 1987 with a real-time 
application written by General Dynamics Corporation. Concurrent Computer Corporation is creating Releases 
2 and 3 of Alpha which arc significantly enhanced and commercial quality; these will be available for experi- 
mental use on their multiprocessor products by the Fall of 1989 and 1990, respectively. Alpha is an open 
operating system in the sense of being both intended and designed for portability to multiple vendors’ hard 
ware, and has begun to emerge as the de facto standard for next-generation mission-oriented real-time opcral 
ing systems. 
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